我刚刚遇到了一个捕获异常（所有异常;我知道这是不好的，但这里不相关）的属性setter，并且只有会记录它们。首先，我认为它应该再次通过他们;为什么要等待崩溃和日志研究，当你可以马上知道有什么事情是错误的？我的主要问题是，我是否对无效的日期值进行验证，向我的文档上的ValidationRules对象添加一个RuleViolation对象，或抛出一个InvalidDate异常，或者让CLR为我抛出异常（无效日期只是无效的日期，没有检查范围等）异常与验证
只要方法或类成员无法完成设计要完成的任何任务，就应抛出异常。
因此，对于属性setter，如果setter无法设置属性，那么它应该抛出一个异常。
至于你是否应该抓住它并重新抛出它，答案是肯定的，但只有当你需要在设置器中立即处理异常之前，将它传递到堆栈之前......但记录它不是做这件事的理由。一般来说，你应该在更高的层次上执行跨层次的异常日志记录，在异常不会被重新抛出的情况下......如果你正在关注堆栈中某些地方的交叉问题， ，绝对不要重新抛出同样的异常。但是，如果您正在编写一个工具或框架库，您希望组件的客户端拥有一组清晰定义的期望异常，并且您已定义了您的组件将向客户端代码抛出的自定义异常，以及哪些客户端组件期望看到，那么您可能希望捕获CLR生成的异常并重新引发您自己的自定义异常。始终在将自定义异常“InnerException”属性传递到堆栈之前包含实际底层异常，所以其中的数据可用于任何最终消耗它的系统。
捕捉和重新抛出是最糟糕的事情。如果你只是想重新推出一下这个观点，那么它对TRY来说代价高昂？例如，如果您需要记录它们，您可以使用catch unhandled exceptions with the global.asax。
在验证方面，从网络角度来看，我总是使用正则表达式验证日期，这些火灾的客户端和服务器端，所以我知道什么时候
if(Page.IsValid)
块内部的IM，我txtDate.Text是一个有效的日期，所以我不打扰检查，因为它只是浪费。
这取决于具体的任务。如果你正在编写一个库类作为其他程序中的一个组件，并且该类的方法的契约说它只应该接受有效日期，那么抛出异常就没有问题。
如果您接受用户输入，然后等待异常是一种不好的做法。在这种情况下，你应该自己验证日期。
例外情况适用于特殊情况，不应该成为您逻辑的一部分。这通常意味着合同被程序员破坏了。
它真的取决于您的应用程序的逻辑。只有在出现异常的情况下才会抛出异常。对于验证这样的事情，取决于对无效数据的容忍度。
当您构建交互式应用程序并且用户可能输入任何内容时，文档进入无效状态可能是确定的，您应该通过文档类上的属性公开验证信息。
如果您正在处理来自数据库或日志文件的预先准备好的文档，那么文档无效并继续操作可能会破坏系统中的数据可能不正确。当发生这种情况时，你应该抛出
我认为这取决于日期值的来源。如果它来自用户输入或其他可以输入“无效”日期的其他来源，那么验证就是要走的路。另一方面，如果没有可预见的理由为什么数据值可能无效，则抛出异常是适当的。