异常处理设计答案

【问题标题】：exception handling design异常处理设计
【发布时间】：2011-07-02 23:49:25
【问题描述】：

在我当前的项目中，有一些组件/库被设计为适配器。
例如，一个适配器封装了对文件系统的 IO 访问。

在实际的异常处理设计中，适配器必须抛出特定的异常，例如FileSystemFileNotFoundException。
适配器特定异常必须从适配器基本异常派生。

主要原因是开发人员有一个相对好的方法来捕获所有适配器特定的异常。

有时基本异常会提供附加信息，如果是 IO 适配器，源文件和目标文件属性包含每个文件的完整路径和文件名。

主应用程序有三个不同场景的三个自己的基础异常。

有几个从主应用程序调用的适配器。
现在每个适配器在主应用程序中都需要自己的异常映射逻辑。
从适配器映射到应用程序异常类型，对附加异常信息做一些工作等等。

目前需要以下代码将源与目标异常进行映射

        var map = new Dictionary<Type, Type>()
        { typeof(FileAlreadyExistsTechnicalException) } };

        var fileSystemAdapterException = ex as FileSystemAdapterBaseException;
        if (fileSystemAdapterException != null)
        {
            var exception = from mapping in map
                            where mapping.Key.Equals(fileSystemAdapterException.GetType())
                            select mapping.Value;

            var baseTechnicalException = (TechnicalException)Activator.CreateInstance(exception.Single());

            baseTechnicalException.AddPlaceholderEntry(ExceptionPlaceholderConstants.File, fileSystemAdapterException.SourceFile);

            resultException = baseTechnicalException;
        }

        return resultException;

1.) 这是一个好的设计吗？
2.) 如何推广这种映射？
我首先想到了AutoMapper，但他能给我在附加信息上做一些额外工作的可能性吗？

【问题讨论】：

标签： architecture exception-handling mapping automapper

【解决方案1】：

您的第一个问题是：“这是一个好的设计吗？”。如果不深入了解更多细节并了解大局，很难回答这个问题。但鉴于你提供的一切，我必须回答：“不”。这不是一个好的设计，因为它非常复杂。在我看来，您的异常处理比为其构建的实际系统更复杂。记住，我只是猜测。如果我是一名必须支持您的代码库的开发人员，我只会有一个问题：“为什么？？？”。为什么要将必须尽可能简单的异常处理封装到自己的范式中？

您有适配器和相应的异常类，并且希望保留原始异常。异常的美妙之处在于它们被链接起来（至少在 Java/.NET 世界中）。在 Java 中有 Exception.getCause()，在 .NET 中有 Exception.InnerException。在我看来，这就是你所需要的，以及所有其他人所期望的，在不同的抽象层之间处理和传播异常。

【讨论】：

【解决方案2】：

我建议您可以使用通用异常。您可以定义一个异常类 OperationFailedNopException（意味着一个操作以什么都不做的方式失败），然后从它派生一个泛型类类 OperationFailedNopException，其中泛型类型参数是原始抛出异常的类型。想要捕获包装在特定外部异常中的特定类型的内部异常的代码可以这样做。最重要的警告是，我不知道有任何方法可以使这样的事情变变（因此，如果 BarException 派生自 FooException，则抛出的 BarException 可以以这样一种方式包装，即期望 OperationFailedNopException 的东西可以捕获它)。

【讨论】：