1
、
.NET Framework IO Interface and JDK IO Interface
1.1
.
.NET Framework 1.1
public StreamWriter( string path );
异常
1.2 JDK 1.4.2 :
public FileWriter(String fileName) throws IOException
Constructs a FileWriter object given a file name.
Parameters:
fileName
- String The system-dependent filename.
Throws:
IOException
- if the named file exists but is a directory rather than a regular file, does not exist but cannot be created, or cannot be opened for any other reason
2
、解析
.NET
的
Excetpion
是
Unchecked
异常,客户端不要求去
Check
代码,但是
JAVA
的绝大部分
Checked
异常,它要求客户端的代码检测异常。
假设一个这样的场景,方法
OutMethod
调用
InnerMethod
,而内部方法
InnerMethod
抛出的异常
InnerException
。
对于
Java
的
CheckedException
,或者
OutMethod
去抛出
InnerException
,或者
OutMethod
捕捉
InnerException
(然后做处理)。
再来观察一下
JDK
的
FileWriter
的异常声明,我没有详细测试其在各种可能出错情况下抛出的
IOException
的消息,但是其分类远远不如
.NET
的
StreamWriter
。假设
Java
想照抄
.NET
的
StreamWriter
,对于
Java
的使用者来说,无异于恶梦。外部的代码需要捕获如此多的异常消息(不捕捉就会在
OutMethod
抛出一大堆的异常,问题继续传播下去,这是
CheckException
的一个弱点)。也许正是出于这样的问题,所以此处
Java
接口的异常声明比较简单。
那么假设我是一个库设计者,正在用到了
IO
。如果我使用
.NET
进行开发,对于
IOException
来说,我是否有必要捕捉呢?捕捉的目的是为了“处理”,那么对于库设计者,显然这时候需要通知其“客户程序员”出错的原因,所以这里的库设计者的行为最好就是“不处理”。如果处理,那只能是“
catch
、再
throw
”。那么这样的处理显然是无意义的,因为原始异常已经足以提醒客户程序员出错的原因了。如果捕捉,那代码会特别的丑陋(直接
catch Exception
的行为是不可取的)。
CheckedException
的另外一个缺点就是“将
Exceotion
加入了
Interface
的规格声明“。假设
OutMethod
调用了
InnerMethod
,此时
InnerMethod
的设计者需要增加一个异常,那么会直接影响到
OutMethod
。当然这里的
InnerMethod
的设计者此时已经做了“修改接口声明“的行为。
随后待续......