2013-07-26 17 views
0

我試圖理解異常條件從何處派生。我的問題到最後,但我會提出一個可能使其更清晰的例子。例外是基本的,還是可以用條件代替?


以此Java代碼爲例。它具有指向文件的路徑並設置了一個File對象。如果路徑爲空,則拋出異常。

String path = getPathName(); 
try { 
    File file = new File(path); 
} catch (NullPointerException e) { 
    // ... 
} 

這很難說是一個特殊的情況,不過,如果我們能以這樣的方式,這可能是preferrable修改:

String path = getPathName(); 
if (path == null) { 
    path = DEFAULT_PATH; 
} 
File file = new File(path); # we've removed the need for an exception 

但進一步的移動,我們碰上了新的異常時,我們嘗試使File可讀。

try { 
    file.setReadable(true); 
} catch (SecurityException e) { 
    // ... 
} 

我們可以通過檢查兩個條件解決此問題裙子:記住

SecurityManager sm = System.getSecurityManager(); 
if (sm != null && sm.checkWrite(path)) { 
    // modify the SecurityManager 
} else { 
    file.setReadable(true); 
} 

有了這個例子中,我的問題......


如果我們下移堆棧,從Java到OS等等,是否有可能用if-else分支替換所有異常處理代碼?還是有一些例外(硬件?)的根本原因,這意味着它們被「烘烤」到編程中?

+0

爲什麼近距離投票? – sdasdadas

+1

檢查太寬泛的選項。所以,我想有人擔心這會有太多的答案。 – Marcin

+0

啊,我沒有意識到我可以看到推理沒有投票給自己關閉。 – sdasdadas

回答

4

如果我們向下移動堆棧,從Java到OS等等,是否有可能用if-else分支替換所有異常處理代碼?

是的。這就是過去如何完成的,仍然是語言無例外。使用例外是因爲它們在許多方面更容易。主要優點是程序員沒有預料到的情況可以彙總在一般處理程序中;並且有關異常情況的信息不需要明確保存在每個單獨的函數中,直到處理得當。

或者是否有一些異常(硬件?)的根本原因,這意味着它們被「烘焙」到編程中?

也是。一般來說,需要以某種方式處理意外的硬件條件,除非您在這種情況下適應未定義的行爲。

+0

謝謝,這回答我的問題。 – sdasdadas

+0

@sdasdadas不客氣。 – Marcin

0

如果全部程序中的方法返回某種「異常」對象的指針/引用(對於其他返回值,將指針或引用傳遞給調用方分配的存儲位置),並且如果每個來電可能直接或間接想拋出一個異常,每一個方法的東西,如被括號:

ret = callFunction(...parameters...); 
if (ret != NULL) 
    return AddToExceptionStacktrace(ret, ...info about this call site...); 

那麼就沒有必要進行異常處理(注意任何其他形式,如果類型支持範圍的變量,「return」語句必須在代碼實際返回到c之前插入代碼進行清理阿列爾)。

不幸的是,這是很多額外的代碼。這種方法在只有「檢查」異常(意味着一種方法既不能拋出異常也不能傳遞它們通過,除非它被聲明爲這樣做)的語言中是可行的,但是將該開銷添加到可能直接或間接的每個函數調用一個拋出異常的函數將非常昂貴。異常處理機制通常會消除無例外情況下額外開銷的99%,並增加「異常」情況下的開銷。

相關問題