业务类中的例外情况 [英] Exceptions in Business Classes
问题描述
大家好，
我正在尝试决定如何最好地处理业务类中的异常。对于
示例，有时公共属性的值有效范围为
且枚举不可行。
什么是处理这些的最好方法是什么？抛出一个例外，比如
ApplicationException？如果属性是绑定到UI控件的
，你会以不同的方式处理吗？
非常感谢任何提示，指示或指导！
干杯，
Knut
Hi all,
I am trying to decide how to best handle exceptions in Business Classes. For
example, there are times when public properties have valid ranges of values
and enumerations are not feasible.
What is the best way to handle these? Throw an exception such as an
ApplicationException? Do you handle it differently if the property will be
bound to UI Control?
Any hints, pointers, or guidance is greatly appreciated!
Cheers,
Knut
推荐答案
嗨Knut，
" Knut Vonheim" < VO ***** @ msn.com>在消息中写道
新闻：OL ************** @ tk2msftngp13.phx.gbl ...
Hi Knut,
"Knut Vonheim" <vo*****@msn.com> wrote in message
news:OL**************@tk2msftngp13.phx.gbl...
大家好，
我正在尝试决定如何最好地处理业务类中的异常。
例如，有时公共属性的有效范围为
值且枚举不可行。
处理这些的最佳方法是什么？抛出一个异常，比如
ApplicationException？如果该属性将与UI控件绑定，您会以不同的方式处理它吗？
非常感谢任何提示，指示或指导！
Hi all,
I am trying to decide how to best handle exceptions in Business Classes. For example, there are times when public properties have valid ranges of values and enumerations are not feasible.
What is the best way to handle these? Throw an exception such as an
ApplicationException? Do you handle it differently if the property will be
bound to UI Control?
Any hints, pointers, or guidance is greatly appreciated!
在你给出的具体例子中，我会使用
System.ArgumentOutOfRangeException。我还建议您使用ApplicationException避免使用
。 ApplicationException的问题是
它太通用了。没有合理的情况（我可以看到）处理
的ApplicationException与基本的Exception类有任何不同。最近在Brad Abrams的博客中发表的一篇文章（非常好的博客，顺便说一句）：
http://blogs.msdn.com/brada/archive/.../25/96251.aspx
问候，
Daniel
In the specific example you give, I would use
System.ArgumentOutOfRangeException. I would also suggest that you avoid
using ApplicationException. The problem with ApplicationException is that
it''s too generic. There''s no reasonable case (that I can see) for handling
an ApplicationException any differently than the base Exception class. A
recent post in Brad Abrams'' blog points this out (very good blog, btw):
http://blogs.msdn.com/brada/archive/.../25/96251.aspx
Regards,
Daniel
Daniel，
感谢输入！我正在调查你的建议并阅读
链接。
我要做的一件事是确保我的所有异常都有相同的基础
类。我怀疑微软推荐使用
应用程序异常类的原因是他们将来会做出的一些改变。但是，博客中指出
，只要他们来自同一个班级，那时候很容易做出改变。
再次感谢！
干杯，
Knut
" Daniel Pratt" < KO ****************** @ hotmail.com>在消息中写道
news：％2 **************** @ TK2MSFTNGP12.phx.gbl ...
Daniel,
thanks for the input! I am looking into your suggestion and reading up on
the link.
The one thing I will do is to sure all my exceptions have the same base
class. I have a suspicion the reason Microsoft is recommending using
application exception class is some future change they will make. However,
as pointed out in the blog, as long as they are from the same class the
change is easy to make at that time.
Thanks again!
Cheers,
Knut
"Daniel Pratt" <ko******************@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
嗨Knut ，
Knut Vonheim < VO ***** @ msn.com>在消息中写道
新闻：OL ************** @ tk2msftngp13.phx.gbl ...
Hi Knut,
"Knut Vonheim" <vo*****@msn.com> wrote in message
news:OL**************@tk2msftngp13.phx.gbl...
大家好，
我正在尝试决定如何最好地处理业务类中的异常。
Hi all,
I am trying to decide how to best handle exceptions in Business Classes.
对于
示例，有时公共属性的有效范围为
example, there are times when public properties have valid ranges of
值
并且枚举不可行。
处理这些问题的最佳方法是什么？抛出一个异常，比如
ApplicationException？如果属性将
绑定到UI控件，你会以不同的方式处理吗？
非常感谢任何提示，指针或指导！
and enumerations are not feasible.
What is the best way to handle these? Throw an exception such as an
ApplicationException? Do you handle it differently if the property will be bound to UI Control?
Any hints, pointers, or guidance is greatly appreciated!
在您给出的具体示例中，我将使用
System.ArgumentOutOfRangeException。我还建议您避免使用ApplicationException。 ApplicationException的问题在于它太通用了。没有合理的情况（我可以看到）处理ApplicationException，与基本的Exception类不同。最近布拉德艾布拉姆斯的博客上发表了一篇文章（非常好的博客，顺便说一下）：
http://blogs.msdn.com/brada/archive/.../25/96251.aspx
问候，
Daniel
In the specific example you give, I would use
System.ArgumentOutOfRangeException. I would also suggest that you avoid
using ApplicationException. The problem with ApplicationException is that
it''s too generic. There''s no reasonable case (that I can see) for handling
an ApplicationException any differently than the base Exception class. A
recent post in Brad Abrams'' blog points this out (very good blog, btw):
http://blogs.msdn.com/brada/archive/.../25/96251.aspx
Regards,
Daniel
嗨Knut，
" Knut Vonheim" < VO ***** @ msn.com>在消息中写道
news：eJ ************** @ tk2msftngp13.phx.gbl ...
Hi Knut,
"Knut Vonheim" <vo*****@msn.com> wrote in message
news:eJ**************@tk2msftngp13.phx.gbl...
Daniel，
感谢您的投入！我正在研究你的建议并阅读
链接。
我要做的一件事是确保我的所有异常都有相同的基础类。我怀疑微软推荐使用
应用程序异常类的原因是他们将来会做出的一些改变。但是，正如博客中所指出的那样，只要他们来自同一个班级，那时候很容易做出改变。
Daniel,
thanks for the input! I am looking into your suggestion and reading up on
the link.
The one thing I will do is to sure all my exceptions have the same base
class. I have a suspicion the reason Microsoft is recommending using
application exception class is some future change they will make. However,
as pointed out in the blog, as long as they are from the same class the
change is easy to make at that time.
为你的所有异常创建一个公共基类当然是你的
选项，但你应该知道那些告诉你继承所有例外的人b / b $ b公共基类（即ApplicationException）现在是
说不要打扰;而是从System.Exception继承。 Krystof Cwalina
（.NET CLR的程序经理）写道：
精心设计的异常层次结构很宽，不是很深，而且很好/>
只包含那些有针对
捕获的编程方案的例外。
ApplicationException类不是关于防范未来
的变化。相反，如果.NET框架的设计者有机会重新做这件事，那么他们决定不会做出这样的决定。后见之明20-20和所有
那个。
问候，
Daniel
Creating a common base class for all your exceptions is certainly your
option, but you should know that the same people who told you to inherit all
your exceptions from a common base class (i.e. ApplicationException) are now
saying don''t bother; Inherit from System.Exception instead. Krystof Cwalina
(Program Manager for the .NET CLR) writes:
"Well-designed exception hierarchies are wide, not very deep, and
contain only those exceptions for which there is a programmatic scenario for
catching."
The ApplicationException class isn''t about protecting against future
changes. Rather it''s a decision the designers of the .NET framework wouldn''t
make if they had the chance to do it over again. Hindsight 20-20 and all
that.
Regards,
Daniel
这篇关于业务类中的例外情况的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
