如何抛出好的例外？

我听说你永远不应该抛出一个字符串,因为缺少信息,你会发现你不希望捕获的异常.抛出异常有什么好的做法？你继承了一个基本的异常类吗？你有很多例外或很少吗？你做MyExceptionClass&或const MyExceptionClass&？此外,我知道永远不应该在析构函数中抛出异常

我将补充说,我理解设计合同以及何时抛出异常.我问我应该如何抛出异常.

在我看来,如果一个函数不能保持其"承诺",如果它必须打破它的"契约",它应该抛出异常.函数的签名(名称和参数)决定了它的合同.

鉴于这两个成员函数:

const Apple* FindApple(const wchar_t* name) const;
const Apple& GetApple(const wchar_t* name) const;

这些函数的名称及其返回值向我表明,在FindApple的情况下,当找不到正确的苹果时,该函数完全能够返回NULL,但在GetApple的情况下,您期望苹果返回.如果第二个函数不能保证其承诺,它必须抛出异常.

例外是指那些功能无法以其他方式报告这些条件的特殊情况.如果您决定将其作为承诺的一部分(读取:函数签名),那么它可以报告该条件而不抛出异常.

请注意,在FindApple的情况下,由调用者决定如何处理"找不到合适的苹果"的条件,因为它不再是特殊条件.

您可能会试图避免所有异常,但这意味着您必须考虑所有可能的异常情况,并且您将负担放在调用方上.调用者需要检查"错误条件".

最终,需要处理异常,但只能由知道如何以有用的方式处理特定条件的调用者来处理.我的意思是最广泛的解释:放弃的服务稍后会再次尝试,提供有用的错误消息的UI,提供"oops"屏幕的网络应用程序,但恢复得很好,......等等.

戴夫

一个基本的事情是仅为特殊情况保留例外.不要将它们用于流量控制.例如,"找不到文件"不应该是例外,它应该是错误代码或返回值(除非文件必须存在,例如配置文件).但是如果文件在处理时突然消失,那么抛出异常是一个不错的选择.

当少量使用异常时,您不需要将代码转换为try-catch -spaghetti,以避免从较深层接收难以理解的上下文异常.