例外与验证

这取决于手头的具体任务。如果您正在编写一个库类，该类将用作其他程序中的组件，并且该类的方法的合同规定它应该只接受有效日期，那么抛出Exception就可以了。

如果您接受用户输入，然后等待异常是一种糟糕的做法。在这种情况下，您应该自己验证日期。

例外情况适用于例外情况，不应成为您逻辑的一部分。这通常意味着程序员违反了合同。

当方法或类成员无法完成其设计要完成的任何任务时，都应该抛出异常。

因此，对于属性setter，如果setter无法设置属性，那么它应该抛出异常。

至于是否应该捕获并重新抛出它，答案是肯定的，但前提是您需要在将异常传递到堆栈之前立即在setter中处理异常。。。但记录它并不是这样做的理由。一般来说，您应该在更高的级别上实现异常的横切日志记录，这样异常就不会被重新抛出。。。如果你正在处理那些更高层次的交叉问题，那么不，绝对不要捕获并重新抛出相同的异常。

但是，如果您正在编写一个工具或框架库，希望您的组件的客户端具有一组明确定义的预期异常，并且您已经定义了自己的自定义异常，您的组件将向客户端代码抛出这些异常，以及哪些客户端组件将期望看到这些异常，那么您可能希望捕获CLR生成的异常，并重新引发您自己的自定义异常。。在将实际基础异常传递到堆栈之前，请始终将其包含在自定义异常"InnerException"属性中，以便其中的数据可用于最终使用它的任何系统。

它实际上取决于应用程序的逻辑。只有在异常的情况下才应该真正抛出异常。对于验证之类的东西，它取决于对无效数据的容忍度。

当您正在构建一个交互应用程序，并且用户可以输入任何内容时，文档可能会进入无效状态，您应该通过文档类上的属性公开验证信息。

如果您正在处理数据库或日志文件中预先准备好的文档，那么文档无效可能是不正常的，之后继续操作可能会损坏系统中的数据。当这种情况发生时，你应该投球。

我认为这取决于日期值的来源。如果它来自用户输入或其他完全可能输入"无效"日期的来源，那么验证将是可行的。另一方面，如果没有可预见的原因说明数据值可能无效，那么抛出异常是合适的。

抓住并重新思考是最糟糕的事情。尝试起来很昂贵，如果你只是想重新思考有什么意义？您可以使用global.asax捕获未处理的异常，例如，如果您需要记录它们。

在验证方面，从web的角度来看，我总是使用regex验证器来验证日期，这些验证器会激发客户端和服务器端，这样我就知道我何时在中

if(Page.IsValid)

阻止我的txtDate。短信是一个有效的日期，所以我不必检查，因为这只是浪费。