Is there a reason for NOT using the .NET Framework exception classes defined in your own code?

Question

So, we use the Enterprise Library 4.1 Exception Handling Unit to handle exceptions to deal with the registration / handling of our exceptions in a multi-project application. We have several custom exceptions and some exceptions are thrown whose classes are defined in the standard .NET Framework class libraries (e.g. ArgumentException, InvalidOperationException, ArgumentNullException, etc.).

Today, our team’s leadership decided that he didn’t want us to use the latter, since the .NET infrastructure threw these types of exceptions and to facilitate filtering using application block policies, we should use only custom exceptions when the standard library exceptions are almost duplicated .NET class with custom versions, e.g. in CustomArgumentException, CustomInvalidOperationException, etc.

My question is: what's wrong with this approach? At that time I could not put my finger on her, but it was bad for me, and I could not shake my uneasy feelings about this. Am I worried about something that is really not that important? I think it's just like the tail wagging the dog here a little ...

Answer 1

Hk. What I don't like about this:

• It duplicates existing types.
• This violates the principle of least surprise.
• This means that if you want to find wherever you used the wrong argument value (say), you need to look for two type hierarchies, and not just look for ArgumentException .

I would advise you to bring your team to read article 60 Effective Java 2nd Edition . Yes, it's about Java, not C #, but the principles remain the same.

Answer 2

Wireframe design guidelines (first edition) by Krzysztof Cwalina and Brad Abrams recommend throwing existing exceptions defined in the System namespaces where you can, and the more specific, the better. If there is no good fit, then create your own exception.

Creating a parallel universe of ArgumentNullException to match System.ArgumentNullException is a duplication of efforts in which I don't see the value. At the end of the day, if your code throws a System.ArgumentNullException instead of a framework class, you can determine from the stack trace that was ultimately responsible.

It smells like unnecessary extra work for the present and the future when it comes to code maintenance time.

Answer 3

I repeat the answers of John Skeet and Kev. I would simply add that if your exception policy wants to consider structure-level exceptions different from your own exceptions, consider using an exception stack trace.

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

Well, Exceptions thrown by your code and thrown by .net base classes should be handled the same way.

Both are probably a symptom of a problem in your code, so they cannot be ignored or filtered!

Answer 5

Throwing .Net exceptions is fine if the exception correctly describes the type of problem you are trying to open (for example, when the argument is null, you should throw an ArgumentNullException). If you find a situation that is not handled by the .Net framework (for example, you want to split 6 by 3, but this is prohibited by your application), you must create a custom exception.