.NET返回值VS抛出的异常的设计问题 [英] .NET Return value vs thrown Exception Design question

问题描述

让我们假设我们有一个方法处理业务位于一类处理这种结构的树形分级数据结构。

Let's assume we have a method handling operations in a tree hierarchical data structure located in a class handling such a structure.

让我们来看看这些方法之一更近：

Let's look closer at one of those methods:

void MoveNode(Node currentNode, Node newParentNode)
{
    /* check if new parent isn't current's child already */
     if (newParentNode.LMargin < currentNode.LMargin && newParentNode.RMargin > currentNode.RMargin)
     {
        //DO WORK
     }
     else throw new ArgumentException("New parent node cannot be current's own child");
}

MSDN规定：不抛出异常，控制流量

MSDN states: do not throw Exceptions to control the flow !

我的提问：是这样使用的ArgumentException的好吗在您看来，或者你会使用某种类型的返回值。 如果是的话，你会如何提供错误/验证消息。

My question: is this use of ArgumentException alright in your opinion, or would you use some kind of a return value. If so, how would you supply the error/validation message.

推荐答案

由于异常被抛出指示的错误在这里，因此，它不会被丢进在正常工作程序和异常是正确的选择。

Since the exception being thrown indicates a bug here, and it thus won't be ever thrown in a correctly working program and exception is the right choice.

有什么你不应该做的是：

What you should not do is:

try
{
   MoveNode(...)
   //Do something
}
catch(ArgumentException e)
{
  //Do something else
}

在这个例子中，你期望的异常被抛出规律，并用它来控制的控制流程。在调用者捕获了的ArgumentException 几乎总是一个坏主意。这种异常只能夹在顶层处理程序，如果在所有。

In that example you expect the exception being thrown regularly and use it to control the control flow. Catching an ArgumentException in the caller is almost always a bad idea. This kind of exception should only be caught in the top-level handler, if at all.

我个人不喜欢你else子句中抛出异常。我preFER当仁不让的参数检查在函数的开始，随后立即抛出异常。这prevents内的多个嵌套的非错误code。如果块。

Personally I don't like you throwing the exception in the else clause. I prefer doing my parameter checking at the beginning of the function and throw the exception immediately afterwards. That prevents nesting the non error code within multiple if blocks.

有三种类型的异常

1. 在异步异常像计算器，内存不足和ThreadAborted。他们可以在任何地方发生，并不能真正处理
2. 类似的ArgumentException错误例外，记录他们在顶层的处理程序和修复bug
3. 在预计的异常，表明可以在本地句柄错误。通常情况下，你使用这些错误时，是罕见的，你不能预先知道的操作将导致错误。 IO错误就是其中一个典型的例子。
   的原因通常是外部的。例如，一个不可访问的文件，网络故障或无效的数据，你要解析的文件。

1. Asynchronous exception like StackOverflow, OutOfMemory and ThreadAborted. They can happen anywhere and can't really be handled
2. Bug exceptions like ArgumentException, log them in the top level handler and fix the bug
3. Expected exceptions indicating an error that can be handles locally. Typically you use these when errors are uncommon, and you can't know beforehand that an operation will cause an error. IO errors are a typical example of this.
   The cause is typically external. For example an inaccessible file, a network failure or invalid data in a file you're trying to parse.

埃里克利珀谈论这类异常的博客条目：的令人烦恼异常

Eric Lippert talk about these kinds of exception in a blog entry: Vexing exceptions

在使用第三类异常，以及何时使用的返回值是一个主观判断。

When to use the third kind of exception, and when to use return values is a judgment call.

这篇关于.NET返回值VS抛出的异常的设计问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！