blocks|key|1443314|text|MSDN:捕获和抛出标准异常类型|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1443315|http://msdn.microsoft.com/en-us/library/ms229007.aspx|offset|length|1443316|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|1H|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@$D|O|E|P|1|Q]]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|C]]]]

MSDN: Catching and Throwing Standard Exception Types

<a href="http://msdn.microsoft.com/en-us/library/ms229007.aspx" rel="nofollow noreferrer">http://msdn.microsoft.com/en-us/library/ms229007.aspx</a>

blocks|key|1228490|text|这些都记录在MSDN中(在其他答案中链接)，但这里有一个一般的经验法则……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1228491|在setter中，如果您的属性应该在type之上和之外进行验证。例如，名为PhoneNumber的属性可能应该具有正则表达式验证，并且如果格式无效，则应该抛出错误。|1228492|对于getter，可能是当值为null时，但最有可能的是您希望在调用代码中处理该问题(根据设计指南)。|1228493|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

This is all documented in MSDN (as linked to in other answers) but here is a general rule of thumb...

In the setter, if your property should be validated above and beyond type. For example, a property called PhoneNumber should probably have regex validation and should throw an error if the format is not valid. 

For getters, possibly when the value is null, but most likely that is something you will want to handle on the calling code (per the design guidelines).

blocks|key|1228552|text|从setter抛出异常并没有什么错。毕竟，还有什么更好的方法来表明该值对于给定属性无效呢？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1228553|对于getter来说，这通常是不受欢迎的，这很容易解释:一般情况下，属性getter会报告对象的当前状态；因此，getter抛出的唯一合理的情况是状态无效。但通常也被认为是一个好主意，设计你的类，使得最初不可能获得无效的对象，或者通过正常的方法将它置于无效状态(即，始终确保构造函数中的完全初始化，并尝试使方法在状态有效性和类不变式方面是异常安全的)。只要你坚持这个规则，你的属性getter就永远不会遇到必须报告无效状态的情况，因此永远不会抛出。|1228554|我知道有一个例外，实际上它是一个相当重要的例外:任何实现IDisposable的对象。Dispose专门用作使对象进入无效状态的一种方法，在这种情况下甚至可以使用一个特殊的异常类ObjectDisposedException。在对象被释放之后，从任何类成员抛出ObjectDisposedException是非常正常的，包括属性getter(不包括Dispose本身)。|offset|length|style|CODE|1228555|entityMap^0|0|0|S|B|17|7|2H|N|3M|N|4U|7|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@$F|O|G|P|H|I]|$F|Q|G|R|H|I]|$F|S|G|T|H|I]|$F|U|G|V|H|I]|$F|W|G|X|H|I]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$]]

There's nothing wrong with throwing exceptions from setters. After all, what better way to indicate that the value is not valid for a given property?

For getters, it is generally frowned upon, and that can be explained pretty easily: a property getter, in general, reports the current state of an object; thus, the only case where it is reasonable for a getter to throw is when the state is invalid. But it is also generally considered to be a good idea to design your classes such that it is simply not possible to get an invalid object initially, or to put it into invalid state via normal means (i.e., always ensure full initialization in constructors, and try make methods exception-safe with respect to state validity and class invariants). So long as you stick to that rule, your property getters should never get into a situation where they have to report invalid state, and thus never throw.

There is one exception I know of, and it's actually a rather major one: any object implementing <code>IDisposable</code>. <code>Dispose</code> is specifically intended as a way to bring object into an invalid state, and there's even a special exception class, <code>ObjectDisposedException</code>, to be used in that case. It is perfectly normal to throw <code>ObjectDisposedException</code> from any class member, including property getters (and excluding <code>Dispose</code> itself), after the object has been disposed.

blocks|key|1443637|text|处理异常的一个很好的方法是使用它们为您自己和其他开发人员记录代码，如下所示：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1443638|异常应该是针对异常程序状态的。这意味着你可以在任何你想要的地方编写它们！|1443639|您可能希望将它们放在getter中的一个原因是对类的API进行文档化--如果程序员试图错误地使用它时，软件就抛出异常，那么他们就不会错误地使用它！例如，如果您在数据读取过程中进行了验证，那么如果数据中存在致命错误，那么继续并访问该过程的结果可能就没有意义了。在这种情况下，如果有错误，您可能希望获取输出抛出，以确保另一个程序员检查此条件。|1443640|它们是记录子系统/方法/任何东西的假设和边界的一种方式。在一般情况下，它们不应该被捕获！这也是因为如果系统以预期的方式协同工作，它们永远不会被抛出:如果发生异常，它表明一段代码的假设没有得到满足-例如，它没有以最初打算的方式与周围的世界交互。如果您捕获到为此目的编写的异常，则可能意味着系统已进入不可预测/不一致的状态-这可能最终导致数据崩溃或损坏或类似的，这可能更难检测/调试。|1443641|异常消息是报告错误的一种非常粗略的方式-它们不能被集中收集，并且只包含一个字符串。这使得它们不适合于报告输入数据中的问题。在正常运行中，系统本身不应进入错误状态。因此，它们中的消息应该是为程序员设计的，而不是为用户设计的-输入数据中的错误可以被发现，并以更合适的(自定义)格式传递给用户。|1443642|异常(哈哈！)这条规则是像IO这样的东西，其中异常不在您的控制之下，并且不能预先检查。|1443643|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

One nice approach to Exceptions is to use them to document code for yourself and other developers as follows:

Exceptions should be for exceptional program states. This means it's fine to write them wherever you want!

One reason you might want to put them in getters is to document the API of a class - if the software throws an exception as soon as a programmer tries to use it wrong then they wont use it wrong! For instance if you have validation during a data reading process it may not make sense to be able to continue and access the results of the process if there were fatal errors in the data. In this case you may want to make getting the output throw if there were errors to ensure that another programmer checks for this condition.

They are a way of documenting the assumptions and boundaries of a subsystem/method/whatever. In the general case they should not be caught! This is also because they are never thrown if the system is working together in the way expected: If an exception happens it shows that the assumptions of a piece of code are not met - eg it is not interacting with the world around it in the way it was originally intended to. If you catch an exception that was written for this purpose it probably means the system has entered an unpredictable/inconsistent state - this may ultimately lead to a crash or corruption of data or similar which is likely to be much harder to detect/debug.

Exception messages are a very coarse way of reporting errors - they cannot be collected en-masse and only really contain a string. This makes them unsuitable for reporting problems in input data. In normal running the system itself should not enter an error state. As a result of this the messages in them should be designed for programmers and not for users - things that are wrong in input data can be discovered and relayed to users in more suitable (custom) formats.

The Exception (haha!) to this rule is things like IO where exceptions are not under your control and cannot be checked for in advance.

blocks|key|1443723|text|这是一个非常复杂的问题，答案取决于你的对象是如何使用的。根据经验，“后期绑定”的属性getter和setter不应该抛出异常，而只具有“早期绑定”的属性应该在需要时抛出异常。顺便说一句，在我看来，微软的代码分析工具对属性的使用定义太窄了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1443724|“后期绑定”意味着属性是通过反射找到的。例如，Serializeable“属性用于通过对象的属性序列化/反序列化对象。在这种情况下，在过程中抛出异常会以灾难性的方式破坏事情，并且不是使用异常来生成更健壮的代码的好方法。|1443725|“早期绑定”意味着属性的使用是由编译器在代码中绑定的。例如，当您编写的某些代码引用属性getter时。在这种情况下，可以在有意义的时候抛出异常。|1443726|具有内部属性的对象具有由这些属性的值确定的状态。表示可识别和敏感于对象内部状态的属性的属性不应用于后期绑定。例如，假设您有一个必须打开、访问然后关闭的对象。在这种情况下，在不先调用open的情况下访问属性会导致异常。假设，在这种情况下，我们不抛出异常，并且允许代码在不抛出异常的情况下访问值？即使代码从一个无意义的getter中获得了一个值，它看起来也很好用。现在，我们已经将调用getter的代码放在了一个糟糕的位置，因为它必须知道如何检查值，看看它是否是无意义的。这意味着代码必须对它从属性getter获得的值进行假设，以便对其进行验证。这就是糟糕的代码的编写方式。|1443727|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

This is a very complex question and answer depends on how your object is used. As a rule of thumb, property getters and setters that are "late binding" should not throw exceptions, while properties with exclusively "early binding" should throw exceptions when the need arises. BTW, Microsoft's code analysis tool is defining the use of properties too narrowly in my opinion.

"late binding" means that properties are found through reflection. For example the Serializeable" attribute is used to serialize/deserialize an object via its properties. Throwing an exception during in this kind of situation breaks things in a catastrophic way and is not a good way of using exceptions to make more robust code.

"early binding" means that a property use is bound in the code by the compiler. For example when some code that you write references a property getter. In this case it is OK to throw exceptions when they make sense. 

An object with internal attributes has a state determined by the values of those attributes. Properties expressing attributes that are aware and sensitive to the object's internal state should not be used for late binding. For example, lets say you have an object that must be opened, accessed, then closed. In this case accessing the properties without calling open first should result in an exception. Suppose, in this case, that we do not throw an exception and we allow the code access to a value without throwing an exception? The code will seem happy even though it got a value from a getter that is non-sense. Now we have put the code that called the getter in a bad situation since it must know how to check the value to see if it is non-sense. This means that the code must make assumptions about the value that it got from the property getter in order to validate it. This is how bad code gets written.

blocks|key|1228796|text|我有这段代码，我不确定要抛出哪个异常。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1228797|public+Person
{
++++public+string+Name+{+get;+set;+}
++++public+boolean+HasPets+{+get;+set;+}
}

public+void+Foo(Person+person)
{
++++if+(person.Name+==+null)+{
++++++++throw+new+Exception("Name+of+person+is+null.");
++++++++//+I+was+unsure+of+which+exception+to+throw+here.
++++}

++++Console.WriteLine("Name+is:+"+%2B+person.Name);
}|code-block|syntax|javascript|1228798|我首先通过在构造函数中强制该属性作为参数来防止模型的属性为空。|1228799|public+Person
{
++++public+Person(string+name)
++++{
++++++++if+(name+==+null)+{
++++++++++++throw+new+ArgumentNullException(nameof(name));
++++++++}
++++++++Name+=+name;
++++}

++++public+string+Name+{+get;+private+set;+}
++++public+boolean+HasPets+{+get;+set;+}
}

public+void+Foo(Person+person)
{
++++Console.WriteLine("Name+is:+"+%2B+person.Name);
}|1228800|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

I had this code where I was unsure of which exception to throw.

<pre><code>public Person
{
 public string Name { get; set; }
 public boolean HasPets { get; set; }
}

public void Foo(Person person)
{
 if (person.Name == null) {
 throw new Exception("Name of person is null.");
 // I was unsure of which exception to throw here.
 }

 Console.WriteLine("Name is: " + person.Name);
}
</code></pre>

I prevented the model from having the property being null in the first place by forcing it as an argument in the constructor.

<pre><code>public Person
{
 public Person(string name)
 {
 if (name == null) {
 throw new ArgumentNullException(nameof(name));
 }
 Name = name;
 }

 public string Name { get; private set; }
 public boolean HasPets { get; set; }
}

public void Foo(Person person)
{
 Console.WriteLine("Name is: " + person.Name);
}
</code></pre>

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.

Best practices: throwing exceptions from properties

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

什么时候从属性getter或setter中抛出异常是合适的？什么时候是不合适的？为什么？链接到这个主题的外部文档会很有帮助...令人惊讶的是，谷歌收视率很低。

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

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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