问最佳实践:从属性引发异常

EN

从setter抛出异常并没有什么错。毕竟，还有什么更好的方法来表明该值对于给定属性无效呢？

对于getter来说，这通常是不受欢迎的，这很容易解释:一般情况下，属性getter会报告对象的当前状态；因此，getter抛出的唯一合理的情况是状态无效。但通常也被认为是一个好主意，设计你的类，使得最初不可能获得无效的对象，或者通过正常的方法将它置于无效状态(即，始终确保构造函数中的完全初始化，并尝试使方法在状态有效性和类不变式方面是异常安全的)。只要你坚持这个规则，你的属性getter就永远不会遇到必须报告无效状态的情况，因此永远不会抛出。

我知道有一个例外，实际上它是一个相当重要的例外:任何实现IDisposable的对象。Dispose专门用作使对象进入无效状态的一种方法，在这种情况下甚至可以使用一个特殊的异常类ObjectDisposedException。在对象被释放之后，从任何类成员抛出ObjectDisposedException是非常正常的，包括属性getter(不包括Dispose本身)。

处理异常的一个很好的方法是使用它们为您自己和其他开发人员记录代码，如下所示：

异常应该是针对异常程序状态的。这意味着你可以在任何你想要的地方编写它们！

您可能希望将它们放在getter中的一个原因是对类的API进行文档化--如果程序员试图错误地使用它时，软件就抛出异常，那么他们就不会错误地使用它！例如，如果您在数据读取过程中进行了验证，那么如果数据中存在致命错误，那么继续并访问该过程的结果可能就没有意义了。在这种情况下，如果有错误，您可能希望获取输出抛出，以确保另一个程序员检查此条件。

它们是记录子系统/方法/任何东西的假设和边界的一种方式。在一般情况下，它们不应该被捕获！这也是因为如果系统以预期的方式协同工作，它们永远不会被抛出:如果发生异常，它表明一段代码的假设没有得到满足-例如，它没有以最初打算的方式与周围的世界交互。如果您捕获到为此目的编写的异常，则可能意味着系统已进入不可预测/不一致的状态-这可能最终导致数据崩溃或损坏或类似的，这可能更难检测/调试。

异常消息是报告错误的一种非常粗略的方式-它们不能被集中收集，并且只包含一个字符串。这使得它们不适合于报告输入数据中的问题。在正常运行中，系统本身不应进入错误状态。因此，它们中的消息应该是为程序员设计的，而不是为用户设计的-输入数据中的错误可以被发现，并以更合适的(自定义)格式传递给用户。

异常(哈哈！)这条规则是像IO这样的东西，其中异常不在您的控制之下，并且不能预先检查。

这些都记录在MSDN中(在其他答案中链接)，但这里有一个一般的经验法则……

在setter中，如果您的属性应该在type之上和之外进行验证。例如，名为PhoneNumber的属性可能应该具有正则表达式验证，并且如果格式无效，则应该抛出错误。

对于getter，可能是当值为null时，但最有可能的是您希望在调用代码中处理该问题(根据设计指南)。