Question

因此，我们使用Enterprise Library 4.1 Exception Handling Application Block来处理在多项目应用程序中记录/处理异常。我们有一些自定义异常，并抛出一些异常，其类在.NET框架的标准类库中定义（例如ArgumentException，InvalidOperationException，ArgumentNullException等）。

今天，我们的团队负责人决定他不希望我们使用后者，因为.NET框架会抛出这些类型的异常，为了便于使用应用程序块的策略进行过滤，我们应该只使用自定义异常，甚至用自定义版本实际复制.NET标准类库异常，如 Custom ArgumentException， Custom InvalidOperationException等。

我的问题是，这种方法有什么问题？我当时无法用手指指着它，但它闻到了我的错误，我无法摆脱对此的不安情绪。我担心的事情真的不是那么重要吗？我想这只是感觉就像尾巴在这里摇尾巴......

Answer 1

伊克。我不喜欢的是：

它复制现有类型
违反最少意外的原则
这意味着如果你想在任何地方找到你使用了错误的参数值（比如说），你必须寻找两种类型的异常层次，而不只是寻找ArgumentException。

我建议你让你的团队领导阅读Effective Java 2nd edition的第60项。是的，它是关于Java而不是C＃ - 但原则保持不变。

Answer 2

Krzysztof Cwalina和Brad Abrams的Framework Design Guidelines书（第一版）建议尽可能地在System命名空间中定义现有的异常，并且越具体越好。如果不合适，则抛出自定义异常。

创建自定义 ArgumentNullException的并行Universe以匹配System.ArgumentNullException，这是我认为没有任何价值的重复工作。在一天结束时，如果您的代码会抛出一个System.ArgumentNullException而不是一个框架类，您可以从最终负责的堆栈跟踪中确定。

在代码维护时间方面，这对当前和未来都有不必要的额外工作。

Answer 3

我赞同Jon Skeet和Kev的回答。我只想补充一点，如果您的异常策略想要处理与您自己的异常不同的框架级异常，请考虑使用异常的堆栈跟踪。

// Somewhere within a custom exception handler policy
var frame = new StackTrace(exception).GetFrame(0);
if (frame.GetMethod().DeclaringType.Namespace.StartsWith("MyNamespace.")) 
{
    // Handle exceptions from our code
}
else 
{
    // Handle framework-level exceptions
}

Answer 4

好吧，你的代码引发的异常和.net基类抛出的异常都应该以相同的方式处理。

两者都可能是您的代码中出现问题的症状，因此不应忽略或过滤！

Answer 5

如果异常正确地描述了您尝试公开的问题类型（例如，当参数为null时，您应该抛出ArgumentNullException），则抛出.Net异常就可以了。如果您发现.Net框架未处理的情况（例如，您希望将6除以3但应用程序不允许），则应创建自定义异常。

有没有理由不在自己的代码中使用.NET Framework定义的异常类？

5 个答案: