是否有合理的理由返回异常对象而不是抛出异常对象？

该问题旨在适用于任何支持异常处理的OO编程语言。我使用C＃仅出于说明目的。

通常会在出现无法立即处理代码的问题时引发异常，然后将异常捕获在catch其他位置的子句中（通常是外部堆栈框架）。

问：是否有任何合法的情况不会引发并捕获异常，而只是从方法中返回然后将其作为错误对象传递出去？

之所以提出这个问题，是因为.NET 4的System.IObserver<T>.OnError方法仅表明了这一点：异常作为错误对象传递。

让我们看看另一种情况，验证。假设我遵循传统的观点，因此我在区分错误对象类型IValidationError和ValidationException用于报告意外错误的单独异常类型：

partial interface IValidationError { }

abstract partial class ValidationException : System.Exception
{
    public abstract IValidationError[] ValidationErrors { get; }
}

（System.Component.DataAnnotations名称空间的作用非常相似。）

这些类型可以按如下方式使用：

partial interface IFoo { }  // an immutable type

partial interface IFooBuilder  // mutable counterpart to prepare instances of above type
{
    bool IsValid(out IValidationError[] validationErrors);  // true if no validation error occurs
    IFoo Build();  // throws ValidationException if !IsValid(…)
}

现在我想知道，是否可以不简化以上内容：

partial class ValidationError : System.Exception { }  // = IValidationError + ValidationException

partial interface IFoo { }  // (unchanged)

partial interface IFooBuilder
{
    bool IsValid(out ValidationError[] validationErrors);
    IFoo Build();  // may throw ValidationError or sth. like AggregateException<ValidationError>
}

问：这两种不同方法的优缺点是什么？

是否有任何合法的情况不会引发并捕获异常，而只是从方法中返回然后将其作为错误对象传递出去？

如果从不抛出，那也不例外。它是derived来自Exception类的对象，尽管它没有遵循行为。在这一点上，将其称为Exception纯粹是语义，但我认为不抛出它没有任何错误。在我看来，不引发异常与内部函数捕获异常并防止其传播完全相同。

函数返回异常对象是否有效？

绝对。以下是一些合适的示例清单：

• 异常工厂。
• 一个上下文对象，报告是否有先前的错误作为准备使用的异常。
• 保留先前捕获的异常的函数。
• 创建内部类型异常的第三方API。

不会把它扔坏吗？

抛出异常有点像：“入狱。不要通过Go！” 在棋盘游戏《大富翁》中。它告诉编译器在不执行任何源代码的情况下跳过所有源代码直至捕获。它与错误，报告或停止错误无关。我喜欢将抛出异常作为函数的“超级返回”语句。它将代码的执行返回到比原始调用者更高的位置。

这里重要的是要了解异常的真正价值在于try/catch模式，而不是异常对象的实例化。异常对象只是状态消息。

在您的问题中，您似乎在混淆这两件事的用法：跳转到异常的处理程序，以及异常表示的错误状态。仅仅因为您采取了错误状态并将其包装在异常中并不意味着您就遵循了try/catch模式或其优点。

当您具有分析情况的帮助方法并返回适当的异常后再由调用者抛出的异常时，返回异常而不是抛出异常在语义上是有意义的（可以将其称为“异常工厂”）。在此错误分析器函数中引发异常将意味着在分析本身中出了点问题，而返回异常则意味着已成功分析了错误的种类。

一个可能的用例是将HTTP响应代码转换为异常的函数：

Exception analyzeHttpError(int errorCode) {
    if (errorCode < 400) {
         throw new NotAnErrorException();
    }
    switch (errorCode) {
        case 403:
             return new ForbiddenException();
        case 404:
             return new NotFoundException();
        case 500:
             return new InternalServerErrorException();
        …
        default:
             throw new UnknownHttpErrorCodeException(errorCode);
     }
}

请注意，抛出异常意味着该方法使用错误或发生内部错误，而返回异常意味着该错误代码已成功识别。

从概念上讲，如果异常对象是操作的预期结果，则为是。我能想到的情况在某些时候总是涉及到掷球接球：

• “ Try”模式的变体（一种方法封装了第二种引发异常的方法，但是捕获了异常，而是返回一个指示成功的布尔值）。您可以返回一个抛出的异常（如果成功，则返回null），而不是返回一个布尔值，从而允许最终用户获得更多信息，同时保留无捕获的成功或失败指示。

• 工作流错误处理。在实践中，与“尝试模式”方法封装相似，您可能在命令链模式中抽象了工作流步骤。如果链中的某个链接引发异常，则通常更干净地在抽象对象中捕获该异常，然后通过上述操作将其返回，因此工作流引擎和作为工作流步骤运行的实际代码不需要大量尝试-捕获自己的逻辑。

可以说您将某些任务排队在某个线程池中。如果此任务引发异常，则它是不同的线程，因此您不会捕获它。执行它的线程就死了。

现在，考虑某种（该任务中的代码或线程池实现）捕获该异常并将其与任务一起存储，并认为任务已完成（未成功）。现在，您可以询问任务是否完成（并询问它是否已抛出，或者可以再次在您的线程中抛出（或者更好的是，将新异常以原始原因作为原因））。

如果您手动执行此操作，您会注意到您正在创建新的异常，将其抛出并捕获，然后将其存储在另一个线程中，以检索对其进行抛出，捕获和反应。因此，跳过投掷和捕获并仅将其存储并完成任务，然后仅询问是否存在异常并对它做出反应是有意义的。但这会导致更复杂的代码，如果在同一位置可能确实抛出异常。

PS：这是使用Java编写的，在Java中创建异常时创建堆栈跟踪信息（与在抛出时在C＃中创建堆栈跟踪信息不同）。因此，Java中没有抛出异常的方法将比C＃中的慢（除非它是预先创建和重用的），但是将提供堆栈跟踪信息。

通常，我会远离创建异常并从不抛出异常（除非性能分析后的性能优化指出了瓶颈）。至少在Java中，异常创建非常昂贵（堆栈跟踪）。在C＃中是可能的，但是IMO令人惊讶，因此应避免。

这取决于您的设计，通常我不会将异常返回给调用者，而是会抛出并捕获它们并将其留在那。通常，编写代码会导致早期失败。例如，考虑打开文件并对其进行处理的情况（这是C＃PsuedoCode）：

        private static void ProcessFileFailFast()
        {
            try
            {
                using (var file = new System.IO.StreamReader("c:\\test.txt"))
                {
                    string line;
                    while ((line = file.ReadLine()) != null)
                    {
                        ProcessLine(line);
                    }
                }
            }
            catch (Exception ex) 
            {
                LogException(ex);
            }
        }

        private static void ProcessLine(string line)
        {
            //TODO:  Process Line
        }

        private static void LogException(Exception ex)
        {
            //TODO:  Log Exception
        }

在这种情况下，一旦遇到不良记录，我们将出错并停止处理该文件。

但是请说，要求是即使一行或多行出现错误，我们也要继续处理文件。代码可能看起来像这样：

    private static void ProcessFileFailAndContinue()
    {
        try
        {
            using (var file = new System.IO.StreamReader("c:\\test.txt"))
            {
                string line;
                while ((line = file.ReadLine()) != null)
                {
                    Exception ex = ProcessLineReturnException(line);
                    if (ex != null)
                    {
                        _Errors.Add(ex);
                    }
                }
            }

            //Do something with _Errors Here
        }
        //Catch errors specifically around opening the file
        catch (System.IO.FileNotFoundException fnfe) 
        { 
            LogException(fnfe);
        }    
    }

    private static Exception ProcessLineReturnException(string line)
    {
        try
        {
            //TODO:  Process Line
        }
        catch (Exception ex)
        {
            LogException(ex);
            return ex;
        }

        return null;
    }

因此，在这种情况下，我们将异常返回给调用者，尽管我可能不会将异常返回，而是将某种错误对象返回，因为异常已被捕获并已经处理。这对返回异常没有害处，但是其他调用者可以重新抛出异常，这可能是不希望的，因为异常对象具有该行为。如果希望呼叫者具有重新抛出然后返回异常的能力，否则，请从异常对象中取出信息并构造一个较小的轻量对象，然后返回该对象。快速故障通常是更干净的代码。

对于您的验证示例，由于验证错误可能很常见，因此我可能不会继承异常类或引发异常。如果50％的用户在第一次尝试时都无法正确填写表单，则返回对象而不是引发异常的开销会更少。

问：是否有任何合法的情况不会引发并捕获异常，而只是从方法中返回然后将其作为错误对象传递出去？

是。例如，最近我遇到一种情况，发现ASMX Web服务中引发的异常在结果SOAP消息中不包含元素，因此我必须生成它。

说明性代码：

Public Sub SomeWebMethod()
    Try
        ...
    Catch ex As Exception
        Dim soapex As SoapException = Me.GenerateSoapFault(ex)
        Throw soapex
    End Try
End Sub

Private Function GenerateSoapFault(ex As Exception) As SoapException
    Dim document As XmlDocument = New XmlDocument()
    Dim faultDetails As XmlNode = document.CreateNode(XmlNodeType.Element, SoapException.DetailElementName.Name, SoapException.DetailElementName.Namespace)
    faultDetails.InnerText = ex.Message
    Dim exceptionType As String = ex.GetType().ToString()
    Dim soapex As SoapException = New SoapException("SoapException", SoapException.ClientFaultCode, Context.Request.Url.ToString, faultDetails)
    Return soapex
End Function

在大多数语言（afaik）中，异常附带了一些附加的功能。通常，当前堆栈跟踪的快照存储在对象中。这对于调试非常有用，但也可能涉及内存。

正如@ThinkingMedia已经说过的，您实际上是在使用异常作为错误对象。

在您的代码示例中，似乎主要是为了重用代码和避免编写代码。我个人认为这不是这样做的好理由。

另一个可能的原因是欺骗该语言，以便为您提供带有堆栈跟踪的错误对象。这为错误处理代码提供了更多的上下文信息。

另一方面，我们可以假设保持堆栈跟踪在周围会消耗内存。例如，如果您开始在某个地方收集这些对象，可能会看到不愉快的内存影响。当然，这很大程度上取决于如何在相应的语言/引擎中实现异常堆栈跟踪。

那么，这是个好主意吗？

到目前为止，我还没有看到它被使用或推荐。但这并不意味着什么。

问题是：堆栈跟踪对您的错误处理真的有用吗？或更笼统地说，您想向开发人员或管理员提供哪些信息？

典型的throw / try / catch模式使得有必要进行堆栈跟踪，因为否则您将不知道它来自何处。对于返回的对象，它总是来自被调用的函数。堆栈跟踪可能包含开发人员需要的所有信息，但是可能不那么沉重，更具体。

答案是肯定的。请参阅http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions，并打开有关例外情况的Google C ++样式指南的箭头。您可以在此处看到他们以前决定反对的论点，但是说如果他们不得不再次做下去，他们可能会决定。

但是，值得注意的是，出于类似的原因，Go语言也不会惯用异常。