C++核心準(zhǔn)則?NR.3：不要拒絕使用異常
NR.3: Don't avoid exceptions
NR.3：不要拒絕使用異常
Reason（原因）
There seem to be four main reasons given for not using exceptions:
不使用異常的四個主要原因可能是：
exceptions are inefficient
例外是低效的
exceptions lead to leaks and errors
異常導(dǎo)致泄漏和錯誤
exception performance is not predictable
異常表現(xiàn)不可預(yù)測
the exception-handling run-time support takes up too much space
異常處理運行時支持占用了太多空間
There is no way we can settle this issue to the satisfaction of everybody. After all, the discussions about exceptions have been going on for 40+ years. Some languages cannot be used without exceptions, but others do not support them. This leads to strong traditions for the use and non-use of exceptions, and to heated debates.
我們沒有辦法使這個問題能讓大家都滿意。畢竟，關(guān)于異常的討論已經(jīng)進行了40多年。某些語言離開例外無法使用，但其他語言則根本就不支持例外。這導(dǎo)致使用和不使用例外都形成了強大的傳統(tǒng)，并引發(fā)激烈的辯論。
However, we can briefly outline why we consider exceptions the best alternative for general-purpose programming and in the context of these guidelines. Simple arguments for and against are often inconclusive. There are specialized applications where exceptions indeed can be inappropriate (e.g., hard-real-time systems without support for reliable estimates of the cost of handling an exception).
但是，我們可以簡要概述為什么我們將例外視為本準(zhǔn)則背景下，通用編程的最佳替代方法。?贊成和反對的簡單議論通常是無法形成定論的。在某些特殊的應(yīng)用程序中，異常確實可能是不合適的（例如，不支持可靠估計異常處理成本的硬實時系統(tǒng)）。
Consider the major objections to exceptions in turn
依次考慮對例外的主要反對意見
Exceptions are inefficient: Compared to what? When comparing make sure that the same set of errors are handled and that they are handled equivalently. In particular, do not compare a program that immediately terminate on seeing an error with a program that carefully cleans up resources before logging an error. Yes, some systems have poor exception handling implementations; sometimes, such implementations force us to use other error-handling approaches, but that's not a fundamental problem with exceptions. When using an efficiency argument - in any context - be careful that you have good data that actually provides insight into the problem under discussion.
例外是低效的：與什么相比？比較時，請確保處理了相同的錯誤種類，并且對它們進行了同等的處理。?尤其是，請不要將在看到錯誤后立即終止的程序與在記錄錯誤之前仔細(xì)清理資源的程序進行比較。是的，某些系統(tǒng)的異常處理確實差勁；有時，這樣的實現(xiàn)迫使我們使用其他錯誤處理方法，但這不是例外的根本問題。在任何情況下使用效率論點時，請注意您擁有確實可以洞悉所討論的問題的良好數(shù)據(jù)。
Exceptions lead to leaks and errors. They do not. If your program is a rat's nest of pointers without an overall strategy for resource management, you have a problem whatever you do. If your system consists of a million lines of such code, you probably will not be able to use exceptions, but that's a problem with excessive and undisciplined pointer use, rather than with exceptions. In our opinion, you need RAII to make exception-based error handling simple and safe -- simpler and safer than alternatives.
異常會導(dǎo)致泄漏和錯誤。不會的。如果您的程序是一堆棘手的指針，卻沒有資源管理的整體策略，那么無論您怎么做，都會遇到問題。如果您的系統(tǒng)由一百萬行這樣的代碼組成，您可能將無法使用異常，但這是過度和無序使用指針而不是異常的問題。我們認(rèn)為，您需要RAII才能使基于異常的錯誤處理變得簡單而又安全-與替代方法相比更加簡單和安全。
Exception performance is not predictable. If you are in a hard-real-time system where you must guarantee completion of a task in a given time, you need tools to back up such guarantees. As far as we know such tools are not available (at least not to most programmers).
異常性能是不可預(yù)測的。如果您在硬實時系統(tǒng)中，必須保證在給定時間內(nèi)完成任務(wù)，則需要工具來確保實現(xiàn)此類保證。據(jù)我們所知，此類工具尚不可用（至少對于大多數(shù)程序員而言如此）。
the exception-handling run-time support takes up too much space This can be the case in small (usually embedded systems). However, before abandoning exceptions consider what space consistent error-handling using error-codes would require and what failure to catch an error would cost.
異常處理運行時支持占用了太多空間，在小型（通常是嵌入式系統(tǒng)）中可能是這種情況。但是，在放棄異常之前，請考慮使用錯誤代碼進行一致的錯誤處理將需要多少空間，以及捕獲錯誤的失敗將花費多少。
Many, possibly most, problems with exceptions stem from historical needs to interact with messy old code.
許多（可能是大多數(shù)）異常問題源于與混亂的舊代碼進行交互的歷史需求。
The fundamental arguments for the use of exceptions are
使用例外的基本論據(jù)是
They clearly differentiate between erroneous return and ordinary return
它們清楚地區(qū)分錯誤返回和普通返回
They cannot be forgotten or ignored
它們無法被忘記或忽略
They can be used systematically
它們可以被系統(tǒng)地使用
Remember（記住）
Exceptions are for reporting errors (in C++; other languages can have different uses for exceptions).
異常用于報告錯誤（在C ++中；其他語言對異常的用法可能不同）。
Exceptions are not for errors that can be handled locally.
異常不適用于可以在本地處理的錯誤。
Don't try to catch every exception in every function (that's tedious, clumsy, and leads to slow code).
不要試圖捕獲每個函數(shù)中的每個異常（這很乏味，笨拙，并且會導(dǎo)致低效代碼）。
Exceptions are not for errors that require instant termination of a module/system after a non-recoverable error.
異常不屬于那些在不可恢復(fù)的錯誤之后需要立即終止模塊/系統(tǒng)的錯誤。
Example（示例）
???Alternative（代替選項）
Contracts/assertions: Use GSL's?Expects?and?Ensures?(until we get language support for contracts)
契約/主張：使用GSL的期望和保證（直到我們獲得合同的語言支持）
原文鏈接
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#nr3-dont-avoid-exceptions
新書介紹
《實戰(zhàn)Python設(shè)計模式》是作者最近出版的新書，拜托多多關(guān)注！
本書利用Python 的標(biāo)準(zhǔn)GUI 工具包tkinter，通過可執(zhí)行的示例對23 個設(shè)計模式逐個進行說明。這樣一方面可以使讀者了解真實的軟件開發(fā)工作中每個設(shè)計模式的運用場景和想要解決的問題；另一方面通過對這些問題的解決過程進行說明，讓讀者明白在編寫代碼時如何判斷使用設(shè)計模式的利弊，并合理運用設(shè)計模式。
對設(shè)計模式感興趣而且希望隨學(xué)隨用的讀者通過本書可以快速跨越從理解到運用的門檻；希望學(xué)習(xí)Python GUI 編程的讀者可以將本書中的示例作為設(shè)計和開發(fā)的參考；使用Python 語言進行圖像分析、數(shù)據(jù)處理工作的讀者可以直接以本書中的示例為基礎(chǔ)，迅速構(gòu)建自己的系統(tǒng)架構(gòu)。
覺得本文有幫助？請分享給更多人。
關(guān)注微信公眾號【面向?qū)ο笏伎肌枯p松學(xué)習(xí)每一天！
面向?qū)ο箝_發(fā)，面向?qū)ο笏伎迹?/span>