Checked Exception VS UnChecked Excetion

Checked Exception VS UnChecked Excetion

1 、 .NET Framework IO Interface  and  JDK IO Interface

1.1 ． .NET Framework 1.1

   public StreamWriter(    string path  );

异常

异常类型	条件
UnauthorizedAccessException	访问被拒绝。
ArgumentException	path 为空字符串 ("") 。
ArgumentNullException	path 为空引用（ Visual Basic 中为 Nothing ）。
DirectoryNotFoundException	指定的路径无效，比如在未映射的驱动器上。
PathTooLongException	指定的路径、文件名或者两者都超出了系统定义的最大长度。例如，在基于 Windows 的平台上，路径必须小于 248 个字符，文件名必须小于 260 个字符。
IOException	path 包含不正确或无效的文件名、目录名或卷标的语法。
SecurityException	调用方没有所要求的权限。

 

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 的设计者此时已经做了“修改接口声明“的行为。

 

 

   随后待续......