jinfeng_wang

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 的設計者此時已經做了“修改接口聲明“的行為。

?

?

???隨后待續......?

?

?