異常與返回值在報告錯誤上的優(yōu)勢
與返回值來(lái)報告錯誤相比，異常處理有許多優(yōu)勢，好的框架設計能幫助應用程序開(kāi)發(fā)人員認識到異常所具有的優(yōu)勢。
l 異常增強了API的一致性，這是因為設計異常的唯一目的就是為了報告錯誤。相比之下，返回值就有多種用途。
l 異常已經(jīng)很好的與面向對象結合在一起了，在構造函數，操作符重載以及屬性為例，程序員不可能使用返回值來(lái)報告錯誤是不可能的。只能通過(guò)異常來(lái)處理。
l 在用返回值來(lái)報告錯誤時(shí)候，錯誤處理的代碼與可能會(huì )發(fā)生錯誤的代碼距離總是很近。但是，在使用異常處理的時(shí)候，開(kāi)發(fā)人員就能有更多的選擇。既可以在錯誤發(fā)生附近捕獲異常，也可以在調用棧上層對錯誤進(jìn)行集中處理
l更容易使錯誤處理的代碼局部化。如果使用返回值來(lái)報告錯誤，那么對于那些極其穩固的代碼來(lái)說(shuō)，幾乎是每個(gè)可能出錯的地方都有一個(gè)IF語(yǔ)句，這些IF語(yǔ)句的目的就是對錯誤進(jìn)行處理。如果使用異常來(lái)報告錯誤，那么編寫(xiě)穩固的代碼就要容易很多?？梢园彦e誤處理代碼集中在try代碼后面的模塊，甚至是棧的更高處。
（雖然不應該用返回值來(lái)表示錯誤，但是可以考慮在操作成功情況下用它來(lái)返回一些狀態(tài)信息，比如插入了多少行數據。）
l 錯誤代碼很容易被忽略。另一方面，異常在代碼的控制流中扮演了一個(gè)積極的角色，它使得開(kāi)發(fā)人員無(wú)法忽略通過(guò)異常來(lái)報告錯誤，從而使得代碼變得更加穩固。
（應該指出的是，這意味著(zhù)在測試時(shí)會(huì )發(fā)現更多的BUG,而最終發(fā)行版本將更加穩固，另外，由于發(fā)行代碼更加穩固，當真正投入使用的時(shí)候，拋出異常的數量可能會(huì )非常少）
l使用基于返回值的錯誤處理模型時(shí)，如果調用API失敗，那么程序很有可能會(huì )在結果不正確的情況下繼續運行，并在后來(lái)導致程序崩潰或者數據損壞。在使用基于異常的處理模型時(shí)候，一旦發(fā)生錯誤，線(xiàn)程就被停止。調用代碼會(huì )有機會(huì )對異常進(jìn)行處理。如果調用棧上方?jīng)]有任何方法對異常進(jìn)行處理，那么應用程序即被終止。終止應用程序逼讓它繼續不正常運行要好得多。
l 異?？梢园S富的信息來(lái)對錯誤的原因進(jìn)行描述
l異常允許用戶(hù)定義未處理的異常的處理程序（就是普通的Catch塊）理想情況下，應用程序應高足夠智能，可以處理所有異常，但是這不現實(shí)，因為開(kāi)發(fā)人員不可能預料到所有的異常。在使用錯誤碼時(shí)候，意外的錯誤通常會(huì )被忽略，程序會(huì )繼續不穩定的運行。如果代碼正確使用了異常，那么處理程序可以把失敗記錄下來(lái)，并且可以關(guān)閉程序。與其繼續讓?xiě)贸绦蜻\行并產(chǎn)生不確定的結果相比，這座做法要可取的多。
l 異常有助于監控，異常是經(jīng)過(guò)精心定義的方法失敗模型。正因為如此，各種工具（比如調試器，性能分析器，性能計數器等）可能會(huì )時(shí)刻注意異常的發(fā)生。
聯(lián)系客服
