我正在为一个项目设计一个基础架构，我一直在想，用参数格式化异常消息是否是个好主意，使其动态化。
这意味着，一方面，异常消息可能非常冗长。
在我看来，不利的一面是你不能期待某些消息。这些可以用于异常处理（尽管这不是最佳实践），测试消息是这个还是那个以及日志记录。但更令人不安的是，如果您打算在某处显示该消息（我就是这样做的），这将使本地化变得更加困难。
所以我的问题是您对此有何看法，以及您是否有一个妥协的解决方案，让我既冗长（以防我记录异常）和一致性。
谢谢。
【问题讨论】：
标签： exception-handling verbosity
我相信在异常中包含参数通常非常有用。想想其他开发人员（以及您自己）会阅读该消息并尝试查找错误。甚至更糟：用户可能会向您阅读异常消息或将其发布在论坛上，而您必须远程找出问题所在。
在异常中测试某些消息确实不是最佳实践。我称之为不好的做法。我知道的所有语言都允许您定义我们自己的异常类，并且如果纯类名对您来说不够好（尽管通常是这样），还可以向该类添加自定义属性。我相信 Exceptions 中的消息应该尽可能地可读，并且不需要通过代码来预测它们。
当然，你可以做任何事。异常消息不应仅仅因为您想在其中包含所有可能的变量而变得太大/太长。明智地选择;-)。
【讨论】：
The parameter {1} at {2} is no good) 之类的东西，以及您在 .NET 中有什么替代方案。我认为这是要走的路。 （顺便说一句，如果您使用字典键，谁来解析它们？？）。是的，将.NET 附带的异常用于默认事物（invalidParameterException 等，不要重新编码），但对于默认事物未涵盖的事物：我认为最好创建自己的。我的意见。