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