代码之家 › 专栏 › 技术社区 › Jason Bunting

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

enterprise-library exception-handling exception .net

6

Jason Bunting · 技术社区 · 16 年前

因此,我们正在使用 Enterprise Library 4.1 Exception Handling Application Block 在多项目应用程序中记录/处理异常。我们有一些自定义异常,并且正在抛出一些异常,这些异常的类在.NET framework的标准类库中定义(例如ArgumentException、InvalidOperationException、ArgumentNullException等)。

今天,我们的团队负责人决定不让我们使用后者,因为.NET framework会抛出这些类型的异常,为了便于使用应用程序块的策略进行过滤,我们应该只使用自定义异常,甚至可以用自定义版本复制.NET标准类库异常,如风俗例外情况, 风俗无效操作异常等。

我的问题是,这种方法有什么错?当时我无法用手指触摸它,但它闻起来有点不对劲,我也无法动摇我对它的不安情绪。我是不是担心一些其实没什么大不了的事情?我想这感觉就像是尾巴在摇狗。。。

5 回复 | 直到 16 年前

1

12

Jon Skeet 16 年前

哎呀。我不喜欢的是:

它复制现有的类型
这意味着,如果你想在任何地方找到你使用了错误的参数值(比如说),你必须寻找两种类型的异常层次结构,而不仅仅是寻找 ArgumentException .

Effective Java 2nd edition . 是的,这是关于Java而不是C的,但原则是一样的。

2

4

Paul Stovell 16 年前

我赞同乔恩·斯基特和凯文的回答。我只是补充说,如果您的异常策略想处理与您自己的异常不同的框架级异常,请考虑使用异常的堆栈跟踪。

// 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
}

3

4

erlando 11 年前

这个 Framework Design Guidelines Krzysztof Cwalina和Brad Abrams的书(第一版)建议抛出 System 可以使用的名称空间,越具体越好。如果不适合,则抛出自定义异常。

ArgumentNullException 相配 System.ArgumentNullException 这是一个重复的工作,我看不到任何价值。在一天结束时,如果您的代码抛出 System.ArgumentNullException 而不是一个框架类,您可以从堆栈跟踪中确定最终的责任人。

在代码维护时间方面,这意味着现在和将来不必要的额外工作。

4

1

Brann 16 年前

那么,代码引发的异常和.net基类引发的异常都应该以相同的方式处理。

这两种情况都可能是一个问题的症状你的

5

0

Matt Ruwe 16 年前