例外情况为返回值 [英] Exceptions as return values

问题描述

我与一些同事进行了热烈的讨论，并决定获得一些关于一个问题的一般性反馈，我可以找到很少的b
指导。为什么使用从System.Exception派生的返回类型定义公共

成员被认为是不好的做法？我理解了拥有干净，简洁的代码的重要性，这些代码遵循广泛接受的模式和做法，但在这种情况下，我发现它
$ b $当一个更好，更优雅的解决方案时，很难盲目地遵循标准

很容易呈现自己。


我正在写一个通用函数来验证数据是将是

用于表示业务对象的关键值。看起来好像

这个：


public static ValidationException ValidateKeyArray（System.Type

targetType，object [] keys）;


ValidationException派生自ApplicationException，它在

转向中派生自基本的Exception类。我选择以这种方式写这个的原因是为了满足这个方法的三个要求：

a）验证本身不应该抛出异常，除非它不能

弄清楚如何验证由于某种原因。
b）调用此方法的代码应该能够确定为什么

验证失败，因此它可以做出适当的响应如果它无法恢复，则抛出

异常

c）弄清楚为什么验证失败不是一个单独的逻辑过程

执行验证本身，所以有一个

单一函数调用来做这两件事是有意义的。


用这种方式写的函数（返回一个类型的对象）

ValidationException）我可以：

1）如果由于输入错误而无法验证，则抛出异常，但

不必抛出异常如果数据格式正确但

无效

2）返回描述性错误ValidationException对象中的消息

3）如有必要，返回多个错误消息（嵌入在

ValidationException对象中或附加到内部异常）

4）在验证时避免破坏正常的程序流程，因为失败

验证不是错误条件

5）向调用者提供一个throwable对象，以便进行关键验证

可以用两行执行（ValidationException x =

ValidateKeyArray（type，array）;如果（x！= null）抛出x;）


据我了解，主要的选择是：


1）返回bool 。这不符合要求（b）和（c）。


2）公开对象的验证信息，比如ASP.NET Page

对象。这将需要一个Validate方法和一个IsValid

属性，或许还有某种列表来提供验证错误

消息。这比我实施的代码要多得多，

并且不符合要求（c）。此外，验证异常将不会以任何方式标准化，因为如果需要，我会依赖调用

代码来抛出异常。


3）总是从ValidateKeyArray方法抛出异常，并且

依赖于调用者使用try ... catch块来管理它。如果你知道输入可能是坏的，你应该避免抛出

例外吗？


4）返回某种非Exception派生类来公开

验证结果。这里唯一真正的缺点是它需要一些额外的代码来从这个对象中提取消息，然后如果你需要抛出它，就会把它放到异常中。
br />

我很期待听到你的想法。


Daniel

I have had a lively discussion with some coworkers and decided to get
some general feedback on an issue that I could find very little
guidance on. Why is it considered bad practice to define a public
member with a return type that is derived from System.Exception? I
understand the importance of having clean, concise code that follows
widely-accepted patterns and practices, but in this case, I find it
hard to blindly follow a standard when a better, more elegant solution
presents itself so readily.

I was writing a generic function to validate data that is going to be
used to represent key values for my business objects. It looked like
this:

public static ValidationException ValidateKeyArray(System.Type
targetType, object[] keys);

ValidationException is derived from ApplicationException, which, in
turn, derives from the base Exception class. The reason I chose to
write this in this way was to meet three requirements for this method:
a) Validation in itself should not throw an exception unless it cannot
figure out how to validate for some reason.
b) The code calling this method should be able to determine why
validation failed so it can either respond appropriately or throw an
exception if it can''t recover
c) Figuring out why validation failed is not a separate logical process
from performing the validation itself, so it makes sense to have a
single function call to do both.

With the function written in this way (returning an object of type
ValidationException) I can:
1) Throw an exception if validation is impossible due to bad input, but
not have to throw an exception if the data is in the correct format but
is invalid
2) Return a descriptive error message in the ValidationException object
3) Return multiple error messages, if necessary (embedded in the
ValidationException object or attached to inner exceptions)
4) Avoid breaking normal program flow when validating, since failed
validation is not an error condition
5) Provide a throwable object to the caller so that critical validation
can be performed in two lines (ValidationException x =
ValidateKeyArray(type, array); if (x != null) throw x;)

As I understand them, the major alternatives are:

1) Returning a bool. This does not meet requirements (b) and (c).

2) Exposing validation information on the object, like the ASP.NET Page
object does. This would require a Validate method and an IsValid
property, and perhaps some sort of list to provide validation error
messages. This is considerably more code than the one I implemented,
and does not meet requirement (c). Also, validation exceptions would
not be standardized in any way, since I would be relying on the calling
code to throw an exception if it needs to.

3) Always throwing exceptions from the ValidateKeyArray method, and
relying on the caller to use a try...catch block to manage it. If you
know that the input could be bad, shouldn''t you avoid throwing an
exception at all?

4) Returning some sort of non-Exception-derived class to expose the
results of validation. The only real disadvantage here is that it
requires some extra code to extract the message from this object and
then put it into an Exception if you need to throw it.

I am looking forward to hearing your thoughts.

Daniel

推荐答案

当我读到你的帖子时，我对这个主题进行了一系列的思考。

最初，我认为你是疯子，你应该冒泡了

异常或捕获并处理它。然而，似乎你在其背后的推理中投入了大量的思考，并且有可能我可以确信，如果我再读一遍，那就确定了b $ b ...不确定。我认为最大的问题是

只是最初的反应是它与某些人违反直觉。


有更好的方法吗？我打算让其他人解决这个问题，

这需要花费很多心思，而且我将在接下来的几个星期内为

做一个相当紧迫的截止日期。


Craig


< dc ***** @ cmcdataworks.com>在消息中写道

news：11 ********************** @ o13g2000cwo.googlegr oups.com ...

As I read your post, I went through a series of thoughts on the topic.
Initially, I thought you were nuts and you should either bubble up the
exception or catch it and handle it. However, it seems like you put a lot
of thought into the reasoning behind it and it''s possible I could be
convinced if I read it again - not sure. I think the biggest problem is
just that the initial reaction is that it''s counterintuitive to some.

Is there a better way to do it? I''m going to let someone else tackle that,
it would take a lot of thought and I''m on a pretty tight deadline for the
next couple weeks.

Craig

<dc*****@cmcdataworks.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

我与一些同事进行了热烈的讨论，并决定对一个我可以找到很少指导的问题得到一些一般性反馈。为什么定义一个派生自System.Exception的返回类型的公共
成员被认为是不好的做法？我理解拥有干净，简洁的代码的重要性，这些代码遵循广泛接受的模式和实践，但在这种情况下，我发现很难盲目地遵循标准，当更好，更多优雅的解决方案
非常容易呈现自己。

我正在编写一个通用函数来验证将用于表示业务对象的键值的数据。它看起来像是这样：

public static ValidationException ValidateKeyArray（System.Type
targetType，object [] keys）;

ValidationException派生自ApplicationException ，在转向中，派生自基础Exception类。我选择以这种方式写这个的原因是为了满足这个方法的三个要求：
a）验证本身不应该抛出异常，除非它无法弄清楚如何验证某些原因。 b）调用此方法的代码应该能够确定验证失败的原因，以便它可以做出适当的响应，或者如果它无法恢复则抛出
异常 c）弄清楚为什么验证失败并不是一个单独的逻辑过程来执行验证本身，所以有一个
单一函数调用来做两者都是有意义的。

使用以这种方式编写的函数（返回类型为
ValidationException的对象），我可以：
1）如果由于输入错误而无法进行验证，则抛出异常，但是不必抛出如果数据格式正确但
无效则出现异常
2）在ValidationException对象中返回描述性错误消息
3）返回多个错误消息sages，如果有必要（嵌入在ValidationException对象中或附加到内部异常）
4）在验证时避免破坏正常的程序流程，因为验证失败
验证不是错误条件
5）向调用者提供一个throwable对象，以便可以在两行中执行关键验证（ValidationException x =
ValidateKeyArray（type，array）; if（x！= null）抛出x;）

据我所知，主要的选择是：

1）返回一个bool。这不符合要求（b）和（c）。
2）公开对象的验证信息，就像ASP.NET页面对象那样。这需要一个Validate方法和一个IsValid
属性，也许还有某种列表来提供验证错误消息。这比我实施的代码要多得多，而且不符合要求（c）。此外，验证异常不会以任何方式标准化，因为如果需要，我会依赖调用代码来抛出异常。

3）总是抛出来自ValidateKeyArray方法的异常，并且依赖于调用者使用try ... catch块来管理它。如果你知道输入可能不好，你不应该避免抛出
异常吗？

4）返回某种非Exception派生类揭露验证结果。这里唯一真正的缺点是它需要一些额外的代码来从这个对象中提取消息，然后如果你需要抛出它就把它放到异常中。

我我很期待听到你的想法。

Daniel

I have had a lively discussion with some coworkers and decided to get
some general feedback on an issue that I could find very little
guidance on. Why is it considered bad practice to define a public
member with a return type that is derived from System.Exception? I
understand the importance of having clean, concise code that follows
widely-accepted patterns and practices, but in this case, I find it
hard to blindly follow a standard when a better, more elegant solution
presents itself so readily.

I was writing a generic function to validate data that is going to be
used to represent key values for my business objects. It looked like
this:

public static ValidationException ValidateKeyArray(System.Type
targetType, object[] keys);

ValidationException is derived from ApplicationException, which, in
turn, derives from the base Exception class. The reason I chose to
write this in this way was to meet three requirements for this method:
a) Validation in itself should not throw an exception unless it cannot
figure out how to validate for some reason.
b) The code calling this method should be able to determine why
validation failed so it can either respond appropriately or throw an
exception if it can''t recover
c) Figuring out why validation failed is not a separate logical process
from performing the validation itself, so it makes sense to have a
single function call to do both.

With the function written in this way (returning an object of type
ValidationException) I can:
1) Throw an exception if validation is impossible due to bad input, but
not have to throw an exception if the data is in the correct format but
is invalid
2) Return a descriptive error message in the ValidationException object
3) Return multiple error messages, if necessary (embedded in the
ValidationException object or attached to inner exceptions)
4) Avoid breaking normal program flow when validating, since failed
validation is not an error condition
5) Provide a throwable object to the caller so that critical validation
can be performed in two lines (ValidationException x =
ValidateKeyArray(type, array); if (x != null) throw x;)

As I understand them, the major alternatives are:

1) Returning a bool. This does not meet requirements (b) and (c).

2) Exposing validation information on the object, like the ASP.NET Page
object does. This would require a Validate method and an IsValid
property, and perhaps some sort of list to provide validation error
messages. This is considerably more code than the one I implemented,
and does not meet requirement (c). Also, validation exceptions would
not be standardized in any way, since I would be relying on the calling
code to throw an exception if it needs to.

3) Always throwing exceptions from the ValidateKeyArray method, and
relying on the caller to use a try...catch block to manage it. If you
know that the input could be bad, shouldn''t you avoid throwing an
exception at all?

4) Returning some sort of non-Exception-derived class to expose the
results of validation. The only real disadvantage here is that it
requires some extra code to extract the message from this object and
then put it into an Exception if you need to throw it.

I am looking forward to hearing your thoughts.

Daniel

Daniel，


我认为这里的主要问题是逻辑结构之一。验证

方法通常会返回true或false - 这是公认的惯例。如果

你认为你的验证方法需要返回更多信息 - 例如

为什么验证失败等等，我会考虑创建一个ValidationResult类

包含这些附加信息，并返回一个实例，而不是异常。

异常是昂贵的，占用了大量的CPU周期，并且出于一个目的，他们真的是b $ b。这是特殊的。


验证失败是正常和预期的业务逻辑结果，并且

不应该导致例外。

希望有所帮助，

彼得

-

创始人，Eggheadcafe.com开发者门户网站：
http://www.eggheadcafe.com

UnBlog：
http://petesbloggerama.blogspot.com


" dc ***** @ cmcdataworks.com&qu OT;写道：

Daniel,

I think the main issue here is one of logical constructs. A validation
method would normally return true or false - that''s accepted practice. If
you feel your validation method needs to return more information -- such as
why validation failed, etc., I''d consider creating a ValidationResult class
containing this additional information, and return an instance of that rather
than an exception.
Exceptions are expensive, rack up a lot of CPU cycles, and they''re really
for one purpose - something Exceptional.

Validation failing is a normal and expected business logic result, and
should not result in an exception.
Hope that helps,
Peter
--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"dc*****@cmcdataworks.com" wrote:

我与一些同事进行了热烈的讨论，并决定对一个我可以找到很少的指导的问题得到一些一般性的反馈。为什么定义一个派生自System.Exception的返回类型的公共
成员被认为是不好的做法？我理解拥有干净，简洁的代码的重要性，这些代码遵循广泛接受的模式和实践，但在这种情况下，我发现很难盲目地遵循标准，当更好，更多优雅的解决方案
非常容易呈现自己。

我正在编写一个通用函数来验证将用于表示业务对象的键值的数据。它看起来像是这样：

public static ValidationException ValidateKeyArray（System.Type
targetType，object [] keys）;

ValidationException派生自ApplicationException ，在转向中，派生自基础Exception类。我选择以这种方式写这个的原因是为了满足这个方法的三个要求：
a）验证本身不应该抛出异常，除非它无法弄清楚如何验证某些原因。 b）调用此方法的代码应该能够确定验证失败的原因，以便它可以做出适当的响应，或者如果它无法恢复则抛出
异常 c）弄清楚为什么验证失败并不是一个单独的逻辑过程来执行验证本身，所以有一个
单一函数调用来做两者都是有意义的。

使用以这种方式编写的函数（返回类型为
ValidationException的对象），我可以：
1）如果由于输入错误而无法进行验证，则抛出异常，但是不必抛出如果数据格式正确但
无效则出现异常
2）在ValidationException对象中返回描述性错误消息
3）返回多个错误消息sages，如果有必要（嵌入在ValidationException对象中或附加到内部异常）
4）在验证时避免破坏正常的程序流程，因为验证失败
验证不是错误条件
5）向调用者提供一个throwable对象，以便可以在两行中执行关键验证（ValidationException x =
ValidateKeyArray（type，array）; if（x！= null）抛出x;）

据我所知，主要的选择是：

1）返回一个bool。这不符合要求（b）和（c）。
2）公开对象的验证信息，就像ASP.NET页面对象那样。这需要一个Validate方法和一个IsValid
属性，也许还有某种列表来提供验证错误消息。这比我实施的代码要多得多，而且不符合要求（c）。此外，验证异常不会以任何方式标准化，因为如果需要，我会依赖调用代码来抛出异常。

3）总是抛出来自ValidateKeyArray方法的异常，并且依赖于调用者使用try ... catch块来管理它。如果你知道输入可能不好，你不应该避免抛出
异常吗？

4）返回某种非Exception派生类揭露验证结果。这里唯一真正的缺点是它需要一些额外的代码来从这个对象中提取消息，然后如果你需要抛出它就把它放到异常中。

我我很期待听到你的想法。

Daniel

I have had a lively discussion with some coworkers and decided to get
some general feedback on an issue that I could find very little
guidance on. Why is it considered bad practice to define a public
member with a return type that is derived from System.Exception? I
understand the importance of having clean, concise code that follows
widely-accepted patterns and practices, but in this case, I find it
hard to blindly follow a standard when a better, more elegant solution
presents itself so readily.

I was writing a generic function to validate data that is going to be
used to represent key values for my business objects. It looked like
this:

public static ValidationException ValidateKeyArray(System.Type
targetType, object[] keys);

ValidationException is derived from ApplicationException, which, in
turn, derives from the base Exception class. The reason I chose to
write this in this way was to meet three requirements for this method:
a) Validation in itself should not throw an exception unless it cannot
figure out how to validate for some reason.
b) The code calling this method should be able to determine why
validation failed so it can either respond appropriately or throw an
exception if it can''t recover
c) Figuring out why validation failed is not a separate logical process
from performing the validation itself, so it makes sense to have a
single function call to do both.

With the function written in this way (returning an object of type
ValidationException) I can:
1) Throw an exception if validation is impossible due to bad input, but
not have to throw an exception if the data is in the correct format but
is invalid
2) Return a descriptive error message in the ValidationException object
3) Return multiple error messages, if necessary (embedded in the
ValidationException object or attached to inner exceptions)
4) Avoid breaking normal program flow when validating, since failed
validation is not an error condition
5) Provide a throwable object to the caller so that critical validation
can be performed in two lines (ValidationException x =
ValidateKeyArray(type, array); if (x != null) throw x;)

As I understand them, the major alternatives are:

1) Returning a bool. This does not meet requirements (b) and (c).

2) Exposing validation information on the object, like the ASP.NET Page
object does. This would require a Validate method and an IsValid
property, and perhaps some sort of list to provide validation error
messages. This is considerably more code than the one I implemented,
and does not meet requirement (c). Also, validation exceptions would
not be standardized in any way, since I would be relying on the calling
code to throw an exception if it needs to.

3) Always throwing exceptions from the ValidateKeyArray method, and
relying on the caller to use a try...catch block to manage it. If you
know that the input could be bad, shouldn''t you avoid throwing an
exception at all?

4) Returning some sort of non-Exception-derived class to expose the
results of validation. The only real disadvantage here is that it
requires some extra code to extract the message from this object and
then put it into an Exception if you need to throw it.

I am looking forward to hearing your thoughts.

Daniel

Daniel，


我对此感到好奇。此外，我认为还需要进行修改。


当彼得说异常费用昂贵时，彼得并不太清楚。

抛出异常是昂贵的。在另一方面创建它们并不是那么贵。当创建异常时，堆栈跟踪

不会被填充（这是我能想到的一件事，那就是构建异常会花费多少资金，但是堆栈跟踪填充

，当它被抛出时，而不是它被创建时，所以这是一个非问题）。


现在，有很多关于使用例如

等其他对象的异常的根深蒂固的想法。我们几乎给人的印象是它们只会被抛出。


然而，它们似乎符合您的需要，并且因为您正在重复使用

现有代码可以满足您的需求，效果很好。


我同意这些使用它的原因，从表面上看，它是一个很好的/>
好​​主意。


但是，在这个讨论中有一件事被忽略了

到目前为止。这是事实，无论你返回什么，都可以通过任何代码段抛出

。这是一个很大的问题，IMO，因为你给了其他

代码来真正抛出一些特定于你的问题领域的东西。

那只是不酷。当然，在C ++中，你可以抛出任何东西（它不会将
限制为从异常派生的对象），但在其他大多数情况下

..NET语言，你必须从例外派生。


仅凭这个原因，我认为创建你自己的

类是个好主意你需要的属性，它表示错误

状态/信息失败的商业逻辑（但不是关键错误）。


希望这会有所帮助。

-

- Nicholas Paldino [.NET / C＃MVP]

- mv*@spam.guard.caspershouse.com

< dc ***** @ cmcdataworks.com>在消息中写道

news：11 ********************** @ o13g2000cwo.googlegr oups.com ...

Daniel,

I have mixed feelings about this. Also, I think that there needs to be
a correction.

Peter wasn''t too clear when he said that exceptions are expensive.
Exceptions are expensive if they are thrown. Creating them, on the other
hand, isn''t that expensive. When an exception is created, the stack trace
isn''t populated (which is the one thing I can think of which would be
expensive in constructing an exception, but the stack trace is populated
when it is thrown, not when it is created, so it is a non issue).

Now, there is a lot of ingrained thinking about using exceptions like
other objects. We are pretty much given the impression that they are only
to be thrown.

However, they seem to suit your need, and because you are reusing
existing code to suit your needs, it works out well.

I agree with these reasons for using it, and on the surface, it is a
good idea.

However, there is one thing that has been neglected in this discussion
up to this point. That is the fact that whatever you return can be thrown
by any section of code. This is a BIG issue, IMO, as you are giving other
code to really throw something which is specific to your problem domain.
That''s just not cool. Granted, in C++, you can throw anything (it doesn''t
have to be limited to an object derived from exception), but in most other
..NET languages, you have to derive from exception.

For that reason alone, I think that it is a good idea to create your own
class which will expose the properties you need, which indicates the error
states/information for failed buisiness logic (but not critical errors).

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
<dc*****@cmcdataworks.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

我与一些同事进行了热烈的讨论，并决定对一个我可以找到很少指导的问题得到一些一般性反馈。为什么定义一个派生自System.Exception的返回类型的公共
成员被认为是不好的做法？我理解拥有干净，简洁的代码的重要性，这些代码遵循广泛接受的模式和实践，但在这种情况下，我发现很难盲目地遵循标准，当更好，更多优雅的解决方案
非常容易呈现自己。

我正在编写一个通用函数来验证将用于表示业务对象的键值的数据。它看起来像是这样：

public static ValidationException ValidateKeyArray（System.Type
targetType，object [] keys）;

ValidationException派生自ApplicationException ，在转向中，派生自基础Exception类。我选择以这种方式写这个的原因是为了满足这个方法的三个要求：
a）验证本身不应该抛出异常，除非它无法弄清楚如何验证某些原因。 b）调用此方法的代码应该能够确定验证失败的原因，以便它可以做出适当的响应，或者如果它无法恢复则抛出
异常 c）弄清楚为什么验证失败并不是一个单独的逻辑过程来执行验证本身，所以有一个
单一函数调用来做两者都是有意义的。

使用以这种方式编写的函数（返回类型为
ValidationException的对象），我可以：
1）如果由于输入错误而无法进行验证，则抛出异常，但是不必抛出如果数据格式正确但
无效则出现异常
2）在ValidationException对象中返回描述性错误消息
3）返回多个错误消息sages，如果有必要（嵌入在ValidationException对象中或附加到内部异常）
4）在验证时避免破坏正常的程序流程，因为验证失败
验证不是错误条件
5）向调用者提供一个throwable对象，以便可以在两行中执行关键验证（ValidationException x =
ValidateKeyArray（type，array）; if（x！= null）抛出x;）

据我所知，主要的选择是：

1）返回一个bool。这不符合要求（b）和（c）。
2）公开对象的验证信息，就像ASP.NET页面对象那样。这需要一个Validate方法和一个IsValid
属性，也许还有某种列表来提供验证错误消息。这比我实施的代码要多得多，而且不符合要求（c）。此外，验证异常不会以任何方式标准化，因为如果需要，我会依赖调用代码来抛出异常。

3）总是抛出来自ValidateKeyArray方法的异常，并且依赖于调用者使用try ... catch块来管理它。如果你知道输入可能不好，你不应该避免抛出
异常吗？

4）返回某种非Exception派生类揭露验证结果。这里唯一真正的缺点是它需要一些额外的代码来从这个对象中提取消息，然后如果你需要抛出它就把它放到异常中。

我我很期待听到你的想法。

Daniel

I have had a lively discussion with some coworkers and decided to get
some general feedback on an issue that I could find very little
guidance on. Why is it considered bad practice to define a public
member with a return type that is derived from System.Exception? I
understand the importance of having clean, concise code that follows
widely-accepted patterns and practices, but in this case, I find it
hard to blindly follow a standard when a better, more elegant solution
presents itself so readily.

I was writing a generic function to validate data that is going to be
used to represent key values for my business objects. It looked like
this:

public static ValidationException ValidateKeyArray(System.Type
targetType, object[] keys);

ValidationException is derived from ApplicationException, which, in
turn, derives from the base Exception class. The reason I chose to
write this in this way was to meet three requirements for this method:
a) Validation in itself should not throw an exception unless it cannot
figure out how to validate for some reason.
b) The code calling this method should be able to determine why
validation failed so it can either respond appropriately or throw an
exception if it can''t recover
c) Figuring out why validation failed is not a separate logical process
from performing the validation itself, so it makes sense to have a
single function call to do both.

With the function written in this way (returning an object of type
ValidationException) I can:
1) Throw an exception if validation is impossible due to bad input, but
not have to throw an exception if the data is in the correct format but
is invalid
2) Return a descriptive error message in the ValidationException object
3) Return multiple error messages, if necessary (embedded in the
ValidationException object or attached to inner exceptions)
4) Avoid breaking normal program flow when validating, since failed
validation is not an error condition
5) Provide a throwable object to the caller so that critical validation
can be performed in two lines (ValidationException x =
ValidateKeyArray(type, array); if (x != null) throw x;)

As I understand them, the major alternatives are:

1) Returning a bool. This does not meet requirements (b) and (c).

2) Exposing validation information on the object, like the ASP.NET Page
object does. This would require a Validate method and an IsValid
property, and perhaps some sort of list to provide validation error
messages. This is considerably more code than the one I implemented,
and does not meet requirement (c). Also, validation exceptions would
not be standardized in any way, since I would be relying on the calling
code to throw an exception if it needs to.

3) Always throwing exceptions from the ValidateKeyArray method, and
relying on the caller to use a try...catch block to manage it. If you
know that the input could be bad, shouldn''t you avoid throwing an
exception at all?

4) Returning some sort of non-Exception-derived class to expose the
results of validation. The only real disadvantage here is that it
requires some extra code to extract the message from this object and
then put it into an Exception if you need to throw it.

I am looking forward to hearing your thoughts.

Daniel

这篇关于例外情况为返回值的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！