最佳实践：从性能抛出异常 [英] Best practices: throwing exceptions from properties

问题描述

当它是适当的从一个属性的getter或setter抛出一个异常？什么时候不适合？为什么？链接到关于这个问题的外部文件将是有益的......谷歌打开了令人惊讶的一点。

When is it appropriate to throw an exception from within a property getter or setter? When is it not appropriate? Why? Links to external documents on the subject would be helpful... Google turned up surprisingly little.

推荐答案

微软有关于如何在<设计性建议href="http://msdn.microsoft.com/en-us/library/ms229006.aspx">http://msdn.microsoft.com/en-us/library/ms229006.aspx

从本质上讲，他们建议该属性的getter是轻量级的访问是始终可以安全地调用。他们建议重新设计干将是方法，如果异常是你需要扔东西。对于制定者，他们表示例外是适当的和可接受的错误处理策略。

Essentially, they recommend that property getters be lightweight accessors that are always safe to call. They recommend redesigning getters to be methods if exceptions are something you need to throw. For setters they indicate that exceptions are an appropriate and acceptable error handling strategy.

有关索引器，微软表示它是可以接受的两个getter和setter抛出异常。而事实上，很多索引在.net库中做到这一点。最常见的例外是 ArgumentOutOfRangeException 。

For indexers, Microsoft indicates that it is acceptable for both getters and setters to throw exceptions. And in fact, many indexers in the .NET library do this. The most common exception being ArgumentOutOfRangeException.

有你为什么不想扔在属性获取一些例外pretty的很好的理由：

There are some pretty good reasons why you don't want to throw exceptions in property getters:

• 由于性能看起来是字段，它并不总是显而易见的，他们可以抛出一个（由设计）异常;而使用方法，程序员进行培训，以期待并调查异常是否调用方法的预期结果。
• 在吸气剂所使用的很多.NET的基础设施，如序列化和数据绑定（在WinForms和WPF为例） - 处理在这样的背景下异常能迅速成为一个问题
• 属性吸气剂自动调试器，当你看或检查对象进行评价。这里有一个例外，可能会造成混淆，放慢你的调试工作。这也是不希望的，以在性能执行其他昂贵操作（如访问数据库）以同样的理由。
• 属性通常用在一个链接约定： obj.PropA.AnotherProp.YetAnother - 用这种语法就成了问题来决定注入的异常catch语句。

• Because properties "appear" to be fields, it is not always apparent that they can throw a (by-design) exception; whereas with methods, programmers are trained to expect and investigate whether exceptions are an expected consequence of invoking the method.
• Getters are used by a lot of .NET infrastructure, like serializers and databinding (in WinForms and WPF for example) - dealing with exceptions in such contexts can rapidly become problematic.
• Property getters are automatically evaluated by debuggers when you watch or inspect an object. An exception here can be confusing and slow down your debugging efforts. It's also undesirable to perform other expensive operations in properties (like accessing a database) for the same reasons.
• Properties are often used in a chaining convention: obj.PropA.AnotherProp.YetAnother - with this kind of syntax it becomes problematic to decide where to inject exception catch statements.

作为一个侧面说明，人们应该意识到，仅仅因为一个属性的没有设计的抛出一个异常，这并不意味着它不会;它可以很容易地调用code，做。即使分配一个新的对象（如字符串）的简单的行为可能会导致异常。你应该总是防守写你的code和期望从任何你调用异常。

As a side note, one should be aware that just because a property is not designed to throw an exception, that doesn't mean it won't; it could easily be calling code that does. Even the simple act of allocating a new object (like a string) could result in exceptions. You should always write your code defensively and expect exceptions from anything you invoke.

这篇关于最佳实践：从性能抛出异常的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！