Freigeben über

Custom Exceptions: When should you create them?

  • Artikel

I think the best answer is: rarely.   It's really hard to go straight to a justification here though.  I find that answering a different question will eventually shed led on when to create a new exception.

"What are the benefits of creating a new/custom exception?"

The answers I come up with or have heard before are ...

  1. Provides a type safe mechanism for a developer to detect an error condition. 

    Without a custom exception a developer would be forced to compare an existing value on an existing exception class in order to determine if a particular error occurred.  To ensure this was unique across applications and environments a unique identifier would need to be inserted as well (likely a GUID).  The resulting code would be quite ugly and maintainability would be a question mark. 

  2. Add situation specific data to an exception

    Ideally this data would help another developer track down the source of the error.

    But an entirely new exception is not needed to achieve this goal. The base Exception class contains a property named Data which is an open dictionary. Any code which raises an exception is free to add custom data into the exception. This data can then be accessed by the handling code. Unique values still need to be dealt with. But in my experience, accessing a GUID based custom property is a bit more accepted than catching an exception based on some GUID property.

    This is especially true now with extension methods. The lack of type safety in the dictionary and potentially constant string sharing for property names could be hidden inside an extension method

  3. No existing exception adequately described my problem

    I'd argue against this because of InvalidOperationException. Invalid operation should cover most exceptional cases

So of these reasons only #1 is a stand alone benefit of a new exception.  Now lets re-state this advantage in the context of the original question.

Creating a new exception allows a developer to catch them

Simple right?  But what benefit does this give to a developer?  From my experience there are only two reasons to catch an exception. 

  • It's a particular for which the underlying exceptional problem can be corrected.  Perhaps the user is prompted to fix the condition by performing some outside action (like re-inserting a disk).
  • Logging errors for post-mortem debugging.  Note: You could also use the Data dictionary and extension methods above to introduce a new method ShouldLog().  This would allow you to avoid creating a new exception type. 

Now I think we can answer the original question of this blog post.

You should only create a new exception if you expect developers to take corrective action for the problem or to log for post mortem debugging.

Otherwise, what benefit does creating this exception give you?

Comments

  • Anonymous
    October 21, 2008
    Thinking about custom exceptions I've made in the last few months, I think all of them fall under the "it's a particular exception for which the underlying exceptional problem can be corrected." Things like parsing a configuration file failed (so I can notify the user of their syntax error), errors in a network stream that mean that a packet was dropped and you should reconnect, etc. Use of exceptions simply makes the code cleaner. But at this point using a custom exception is neccesary, since using a "generic" one IMHO is a risk because you might catch something that indicates an unrelated problem.

  • Anonymous
    October 24, 2008
    .NET New .NET Logos announced today! - ASP.NET Patterns every developer should know Writing a simple

  • Anonymous
    October 24, 2008
    .NETNew.NETLogosannouncedtoday!-ASP.NETPatternseverydevelopershouldknowWritingasi...

  • Anonymous
    November 07, 2008
    Never create custom exceptions.  Follow the .NET evolution from 1.0 to 2.0 by returning useful values from function calls you write instead of throwing exceptions (see the file and directory .NET api changes). We learned through years of C++ usage that custom exceptions are nice in theory but add greatly to code bloat and maintainablity cost over the long term.

  • Anonymous
    November 07, 2008
    The comment has been removed