我刚刚遇到了一个捕获异常的属性设置器（所有异常；我知道这很糟糕，但在这里不相关），并且只记录它们。首先，我认为它也应该再次通过它们；当您可以立即知道有问题时，为什么还要等待崩溃和日志研究？
但是，我的主要问题是，我是否针对无效的日期值进行验证，将 RuleViolation 对象添加到我文档上的 ValidationRules 对象，或者抛出 InvalidDate 异常，或者只是让 CLR 为我抛出异常（无效日期是只是无效的日期，没有检查范围等）
【问题讨论】：
这取决于手头的具体任务。如果您正在编写一个将用作其他程序中的组件的库类，并且该类的方法的合同规定它应该只接受有效日期，那么抛出异常就可以了。
如果您接受用户输入然后等待异常是一种不好的做法。在这种情况下，您应该自己验证日期。
例外是针对特殊情况的，不应成为您逻辑的一部分。这通常意味着程序员违反了合同。
【讨论】：
只要方法或类成员无法完成其设计要完成的任何任务，就应该抛出异常。
所以对于属性设置器，如果设置器无法设置属性，那么它应该抛出异常。
至于你是否应该捕获它并重新抛出它，答案是肯定的，但前提是你需要在 setter 中立即处理异常，然后再将其传递到堆栈中......但记录它不是理由去做。一般来说，您应该在更高级别实现异常的横切日志记录，其中不会重新抛出异常......如果您正在处理堆栈中更高位置的那些横切关注点，那么没有，绝对不要捕获并重新抛出相同的异常。
但是，如果您正在编写一个工具或框架库，您希望您的组件的客户端有一组明确定义的预期异常，并且您已经定义了您自己的自定义异常，您的组件将向客户端代码抛出这些异常，以及期望看到哪些客户端组件，那么您可能希望捕获 CLR 生成的异常并重新抛出您自己的自定义异常。在将实际基础异常传递到堆栈之前，始终将其包含在自定义异常“InnerException”属性中，这样其中的数据可供最终使用它的任何系统使用。
【讨论】：
这实际上取决于您的应用程序的逻辑。只有在异常的情况下才真正抛出异常。对于像验证这样的事情，它取决于对无效数据的容忍度。
当您构建交互式应用程序并且用户可以输入任何内容时，文档进入无效状态可能是正常的，您应该通过文档类的属性公开验证信息。
如果您正在处理来自数据库或日志文件的预先准备好的文档，那么文档无效并继续操作可能会损坏系统中的数据，这可能是不行的。发生这种情况时，您应该扔掉。
【讨论】：
我认为这取决于日期值的来源。如果它来自用户输入或其他很可能输入“无效”日期的来源，那么验证将是可行的方法。另一方面，如果没有可预见的原因导致数据值可能无效，则抛出异常是合适的。
【讨论】：
接住再扔是最糟糕的事情。尝试它的成本很高，如果你只是要重新抛出什么意思？例如，如果您需要记录它们，您可以catch unhandled exceptions with the global.asax。
在验证方面，从网络的角度来看，我总是使用正则表达式验证器作为日期，这些触发客户端和服务器端，所以我知道我什么时候在里面
if(Page.IsValid)
阻止我的 txtDate.Text 是有效日期，所以我不费心检查，因为它只是浪费。
【讨论】：