例外与验证

Question

我刚遇到一个捕获异常的属性设置器（所有异常;我知道这很糟糕，但这里不相关），仅记录它们。首先，我认为应该再次通过它们;为什么等到崩溃和日志研究，你什么时候才能知道什么是错的？

但是，我的主要问题是，我是否对无效日期值进行验证，将RuleViolation对象添加到文档上的ValidationRules对象，或者抛出InvalidDate异常，或者只是让CLR为我抛出​​异常（无效日期是只有无效的日期，没有检查范围等。）

Answer 1

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

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

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

Answer 2

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

Answer 3

只要方法或类成员无法完成它要完成的任何任务，就应该抛出异常。

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

至于你是否应该抓住它并重新抛出它，答案是肯定的，但是只有你需要在setter中立即处理异常，然后再将它传递给堆栈......但是记录它不是理由去做。一般情况下，您应该在更高级别实现异常的跨域日志记录，其中异常不会被重新抛出...如果您正在处理堆栈中某些交叉问题，那么就不会，绝对不要抓住并重新抛出相同的异常。

但是，如果您正在编写工具或框架库，您希望组件的客户端具有明确定义的预期异常集，并且您已定义了自己的组件将抛出到客户端代码的自定义异常，以及哪些客户端组件可能会看到，然后您可能希望捕获CLR生成的异常并重新抛出自己的自定义异常。在将自定义异常“InnerException”属性传递给堆栈之前，始终将其包含在实际的底层异常中，以便其中的数据可用于最终消耗它的任何系统。

Answer 4

这实际上取决于您的应用程序的逻辑。只有在例外的情况下才能真正抛出异常。对于类似验证的内容，它取决于无效数据的容差。

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

如果您正在处理来自数据库或日志文件的预先准备好的文档，那么文档可能无效并且在此之后继续运行可能会损坏系统中的数据。当发生这种情况时，你应该扔掉。

Answer 5

抓捕和重新抛出是最糟糕的事情。如果你只是要重新抛出什么意思，它的价格就贵了？例如，如果您需要记录它们，可以catch unhandled exceptions with the global.asax。

在验证方面，从网络的角度来看，我总是使用正则表达式验证器来表示日期，这些火客户端和服务器端因此我知道什么时候进入内部

if(Page.IsValid)

阻止我的txtDate.Text是一个有效的日期，所以我不打扰检查，因为它只是浪费。