C++異常與錯誤代理

Question

我一直是'無例外'陣營的一部分，但不是那麼虔誠。我有一個關於支持者使用例外經常提出的論點的問題。因此，我最大的（唯一的）C++異常抱怨是代碼的不可預測性。我希望能夠看到代碼（VIM中沒有任何IDE），並且確切地看到它在所有情況下的作用。除了例外，邏輯流程並不明顯，因爲throw和catch可以分開很多邏輯層。

pro-exception異常響應的典型計數器是：「是的，這很糟糕，但是嵌套的錯誤代碼吸得更多。」

嗯，是的，但這是不是的替代方案。如果你知道你的MyClass可能會得到一個XYZ錯誤，並且你想要處理它多個邏輯層，那麼你可以給它傳遞一個指向MyErrorProxy的指針（這是一個指向MyErrorProxy的指針）可以是一個混合，一個接口，或只是一個集中的錯誤處理類）？你不想傳遞指針？好吧，讓它成爲一個線程安全的單例。這需要更多的管道，但它是明確的和非常容易跟蹤邏輯流程。

這就是我一直在編碼很長一段時間。

現在我的問題是：這樣做的真正缺點是什麼？如果您在我離開後很長時間看到此代碼並且您維護它，您會生氣嗎？你真的寧願嘗試（s）並抓住（es）而不是這個機制，爲什麼？

Answer 1

這不是一個好主意。這聽起來像是一個混亂的方式來傳遞錯誤代碼。如果您不想使用例外，則使用錯誤代碼。至少在錯誤代碼中，人們會明白你在做什麼。

另一方面，每當我看到有人避免例外，我認爲他們真的不明白他們的使用。他們一直在談論try/catch。實際上，正確編碼的異常使用有很少的嘗試/捕獲。在我遇到的大多數用例中，異常只是一種將錯誤消息傳回堆棧的方式，以便它可以退出。只有一個try/catch塊，它的主要部分。

當然，我已經編碼了長期存在的服務器，它們不會退出。他們記錄由異常傳遞的消息，將相同的消息返回給客戶端，並繼續等待它們的等待循環。

底線，系統中應該有很少的try/catch塊。一旦你明白了，那麼異常的邏輯流程就變得容易理解了。實際上，它是爲系統設計的。