抛出异常时是否确实需要包含文本描述?

应该记录一个特定的异常,但包含一个文本描述可以让您添加关于当前异常实例的更多上下文。

换句话说,什么是好的 ArgumentException

文本描述非常有用。我认为应该始终包括以下几个原因:

• 它们使您能够清楚地了解异常,而无需在文档中查找。
• 它们允许您国际化异常消息(非常重要)
• 它们提供了一种方法(如果做得好的话),根据情况向最终用户提供更有意义的报告。然而,这必须小心完成(如果终端用户是人类,您不一定要向其显示所有异常)
• 它们提供了一种简单的方法来添加异常日志记录,这比仅仅添加一个类型更有意义
• 它们提供了标准化:异常将满足用户对异常的期望,因为框架基于此信息

是,消息属性和消息构造函数参数是必需的。它们不是多余的。

这是给另一边的开发者的信息,告诉他或她哪里出了问题。例如,仅仅抛出FileNotFoundException是不够的——您应该说出哪个文件。仅仅说在处理web请求时发生了异常是不够的——您应该说是哪个错误,哪个请求。

异常应包括完全诊断问题所需的尽可能多的信息。这几乎总是包括对问题的描述,因为仅仅拥有异常类型不足以跟踪问题。

例如,如果下面的异常没有包含消息,请考虑。你还能找到这个问题吗

• FileNotFoundException
• 参数*异常

当您想要向用户显示异常的结果(尽管i18n使这一点变得有点棘手)或将异常写入日志文件时,使用文本描述非常有用。请记住,文本描述可以包含运行时可用的更多信息,而在记录异常时则不可用。例如 无参数异常 我立刻想到了。

在调试或故障排除时,我最不想做的事情就是不必要地通读文档。我认为有解释性的文字来伴随例外是非常方便的。如果没有提供,我想图书馆真的错过了机会。