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
異常，它要求客戶端的代碼檢測異常。
假設(shè)一個這樣的場景，方法
OutMethod
調(diào)用
InnerMethod
，而內(nèi)部方法
InnerMethod
拋出的異常
InnerException
。
對于
Java
的
CheckedException
，或者
OutMethod
去拋出
InnerException
，或者
OutMethod
捕捉
InnerException
（然后做處理）。
?
再來觀察一下
JDK
的
FileWriter
的異常聲明，我沒有詳細測試其在各種可能出錯情況下拋出的
IOException
的消息，但是其分類遠遠不如
.NET
的
StreamWriter
。假設(shè)
Java
想照抄
.NET
的
StreamWriter
，對于
Java
的使用者來說，無異于惡夢。外部的代碼需要捕獲如此多的異常消息（不捕捉就會在
OutMethod
拋出一大堆的異常，問題繼續(xù)傳播下去，這是
CheckException
的一個弱點）。也許正是出于這樣的問題，所以此處
Java
接口的異常聲明比較簡單。
那么假設(shè)我是一個庫設(shè)計者，正在用到了
IO
。如果我使用
.NET
進行開發(fā)，對于
IOException
來說，我是否有必要捕捉呢？捕捉的目的是為了“處理”，那么對于庫設(shè)計者，顯然這時候需要通知其“客戶程序員”出錯的原因，所以這里的庫設(shè)計者的行為最好就是“不處理”。如果處理，那只能是“
catch
、再
throw
”。那么這樣的處理顯然是無意義的，因為原始異常已經(jīng)足以提醒客戶程序員出錯的原因了。如果捕捉，那代碼會特別的丑陋（直接
catch Exception
的行為是不可取的）。
?
CheckedException
的另外一個缺點就是“將
Exceotion
加入了
Interface
的規(guī)格聲明“。假設(shè)
OutMethod
調(diào)用了
InnerMethod
，此時
InnerMethod
的設(shè)計者需要增加一個異常，那么會直接影響到
OutMethod
。當(dāng)然這里的
InnerMethod
的設(shè)計者此時已經(jīng)做了“修改接口聲明“的行為。
?
?
???隨后待續(xù)......?
?
?