我意识到这可能是主观的，所以会问一个具体的问题，但首先是背景：
我一直是嵌入式软件工程师，但通常在OSI堆栈的第3层或第2层。我不是一个硬件家伙。我一般都经常使用电信产品，通常是手机/手机，这通常意味着像ARM 7处理器一样。
现在我发现自己处于一个更通用的嵌入式世界中，在一个小型初创公司中，我可能会转向“不那么强大”的处理器（这是主观位） - 我无法预测哪个。
我已经阅读了很多关于嵌入式系统中C ++异常处理的争论，但没有明确的答案。有一些关于可移植性的小担忧和一些关于运行时的担忧，但它似乎主要归结为代码大小（或者我正在阅读错误的辩论？）。
现在我必须决定是否使用或放弃异常处理 - 对于整个公司，永远（它将进入一些非常核心的s / w）。
这可能听起来像“一根绳子有多长”，但有人可能会回复“如果你的琴弦是8051，那么就不要。如果，OTOH，那是......”。
我跳哪个方向？超级安全＆amp;失去一个好的功能，或特殊的代码，可能会在以后遇到问题？
答案 0 :(得分：19)
就性能而言，我的理解是异常实际上减小了代码的普通执行路径的大小并提高了性能，但使异常/错误路径更加昂贵。 （通常很多更贵）。
因此，如果你唯一担心的是表现，我会说以后不用担心。如果今天的CPU可以处理它，那么明天也将如此。
然而。在我看来，异常是需要程序员一直所有更聪明的功能之一，而不是程序员可以合理地预期的那样。所以我说 - 如果你可以远离基于异常的代码。远离。
看看Raymond Chen的Cleaner, more elegant, and harder to recognize。他说这比我做得好。
答案 1 :(得分：10)
异常的最大问题 - 它们没有可预测的执行时间。 因此它们不适合硬实时应用程序（我猜大多数嵌入式应用程序都不属于这一类）。
第二个是（可能）增加二进制文件的大小。
我建议你阅读Technical Report on C++ Performance，它专门针对您感兴趣的主题：在嵌入式（包括硬实时系统）中使用C ++，以及如何实现异常处理以及它具有哪些开销。 / p>
答案 2 :(得分：9)
是否使用例外的选择应该取决于它们是否能够很好地适应您的程序的问题域。
我已经广泛使用了C ++异常，无论是在改造旧的C代码还是在一些较新的代码中。 （提示：不要试图重新安装在低内存环境中编写的具有各种不一致异常的20岁C代码。这只是一场噩梦）。
如果您的问题适合处理一个地方的所有错误（例如，某种类型的TCP / IP服务器，其中每个错误条件都满足'分解连接并再试一次'），那么异常是好的 - 您可以在任何地方抛出异常，并且知道它将在何处以及如何处理。
另一方面，如果你的问题不适合中央错误处理，那么异常是一种皇家的痛苦，因为试图找出某些东西（或者应该）被处理的东西很容易成为一种Sisyphean任务。通过查看代码很难看到问题。相反，您必须查看给定函数的调用树，并查看该函数的异常将在何处结束，以便确定您是否有问题。
答案 3 :(得分：4)
如果运行时环境支持异常，我会说适当使用异常。处理特殊情况的例外情况很好，并且根据实现情况可能会产生很少的开销。某些环境不支持它们，尤其是在嵌入式环境中。如果禁止它们，请小心解释原因。我曾经有过一个人，当被告知不要使用例外情况时，他会做一个零除。不完全是我们想到的。