我正在开展一个数字集成的小项目。我一直在阅读像this one这样的主题，当用户提供不良的集成限制，请求不可能的精确度等等时，我无法决定是否应该抛出异常。
此外，如果程序未能在所提供的条件下收敛，该怎么办？我应该抛出异常吗？
现在我所拥有的是整数变量中表示的错误代码，我在许多例程之间传递，但我想减少用户必须声明的变量数量以及必须参考的值。
我正在考虑一种场景，在我上面提到并被用户捕获的情况下，库例程抛出异常。这可以接受吗？如果没有，那会是一个好方法吗？
感谢。
答案 0 :(得分：1)
虽然问题太广泛，但我会尝试提供一些一般性指导，因为这是我经常谈论的主题之一。
一般情况下，当发生的事情确实不应该发生时，例外是有用的。
我可举几个例子。编程错误就是一个 - 当一个函数调用契约被破坏时，我通常会建议抛出异常而不是返回错误。
不可恢复的错误应该触发异常，但是，在呼叫站点上并不总是可以判断可恢复的错误和不可恢复的错误。例如，尝试打开不存在的文件通常是可恢复的错误，这可以保证失败代码。但有时候，文件必须在那里，并且当代码没有调用代码时也没有 - 所以错误变得无法恢复。在后一种情况下，调用代码可能希望文件打开函数抛出异常而不是返回代码。
这引入了异常策略的整个主题 - 告诉函数是否需要抛出异常或返回错误。
答案 1 :(得分：1)
在C ++之前，在性能重要的项目（-fno-exceptions）中避免了异常。现在，异常似乎不会影响效果（请参阅this和this），因此没有理由不使用它们。
偏执但旧的方法是：将程序分为两部分，ui和数字库。 UI可以用任何语言编写并使用异常。数值库是c或c ++，没有例外。例如（胜利，但无关紧要），您可以在c＃中使用一个UI，其异常调用“不安全”的c ++ .dll，其中不使用异常。
替代异常的是经典return -1;，调用者必须检查每个调用的返回值（即使使用optional，调用者仍然必须检查错误）。当执行一系列嵌套函数调用并且在最深的函数中出现错误时，您必须将错误一直传播：您必须在每次调用时检查错误。
使用Exceptions，您可以使用try{}块并在任何调用深度处理内部错误。处理错误的代码只出现一次，并且不会污染您的数字库（或者您正在创建的任何内容）
使用例外！