在抛出异常时是否真的有必要包含文本描述?

时间:2009-08-03 17:38:59

标签: .net exception

当使用任何其他类或第三方库时,人们会期望也会记录异常,因此我总是发现有些多余的文本描述。他们真的有必要吗?

你有什么想法?提前谢谢。

6 个答案:

答案 0 :(得分:3)

应该记录一个特殊的例外,但包含文本描述允许您添加有关当前异常实例的更多上下文。

换句话说,ArgumentException在不知道哪个参数存在问题以及参数触发异常的状态的情况下有什么用呢。

答案 1 :(得分:3)

文字说明非常有用。有几个原因我认为应该总是将它们包括在内:

  • 它们可让您清楚地了解异常情况,而无需在文档中查找。
  • 它们允许传递比“泛型”异常的文档更具体的信息 - 特别是,可以包含有关异常上下文的信息
  • 它们允许您将异常消息国际化(非常重要)
  • 他们提供了一种方法(如果做得好),可以根据具体情况向最终用户提供更有意义的报告。但是,这必须谨慎处理(如果最终用户是个人,你不一定要只显示每个例外。)
  • 它们提供了一种简单的方法来添加比仅仅类型
  • 更有意义的异常日志记录
  • 它们提供标准化:异常将满足用户对异常的期望,因为该框架基于具有此信息

答案 2 :(得分:2)

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

这是向另一方的开发人员发出的信息,告诉他或她出了什么问题。例如,抛出FileNotFoundException是不够的 - 你应该说出哪个文件。仅仅说处理Web请求时发生异常是不够的 - 您应该说出哪个错误以及哪个请求。

答案 3 :(得分:2)

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

例如,考虑以下异常是否包含消息。你还能找到问题吗

  • FileNotFoundException异常
  • 参数*异常

答案 4 :(得分:1)

当您想要向用户显示异常结果时(尽管i18n使这有点麻烦)或者您正在将异常写入日志文件时,有一个文本描述很有用。请记住,文本描述可以包含可能在运行时可用的更多信息,这在记录异常时不可用。像 ArgumentNullException 中的参数名称那样的东西会立即出现。

答案 5 :(得分:1)

在进行调试或故障排除时,我不得不做的最后一件事就是不必要地通过文档阅读。我认为附带例外的解释性文本非常方便。如果没有提供,我认为图书馆真的错过了船。