Common Exception Types


During my recently FrontLine trip I gave a talk on exception handling… One of the points I made is that if possible you should leverage one of the existing exception types in the BCL.  I was asked a couple of times what the common exception types area.   Typically I used it to plug the BCL poster, but I wanted to give you an online version of the data as well. 

 

Next time you go to create a new exception, check here first.  Use or subclass one of these if possible. 

 

 

+–System.Object  

   |

   |

   +–System.Exception  

       |

       |

       +–System.SystemException  

           |

           |

           +–System.ArgumentException  

           |   |

           |   |

           |   +–System.ArgumentNullException  

           |   |

           |   |

           |   +–System.ArgumentOutOfRangeException  

           |   |

           |   |

           |   +–System.DuplicateWaitObjectException  

           |

           |

           +–System.ArithmeticException  

           |   |

           |   |

           |   +–System.DivideByZeroException  

           |   |

           |   |

           |   +–System.OverflowException  

           |   |

           |   |

           |   +–System.NotFiniteNumberException

           |

           |

           +–System.ArrayTypeMismatchException  

           |

           |

           +–System.ExecutionEngineException  

           |

           |

           +–System.FormatException  

           |

           |

           +–System.IndexOutOfRangeException  

           |

           |

           +–System.InvalidCastException  

           |

           |

           +–System.InvalidOperationException  

           |   |

           |   |

           |   +–System.ObjectDisposedException  

           |

           |

           +–System.InvalidProgramException  

           |

           |

           +–System.IO.IOException  

           |   |

           |   |

           |   +–System.IO.DirectoryNotFoundException  

           |   |

           |   |

           |   +–System.IO.EndOfStreamException  

           |   |

           |   |

           |   +–System.IO.FileLoadException  

           |   |

           |   |

           |   +–System.IO.FileNotFoundException  

           |   |

           |   |

           |   +–System.IO.PathTooLongException  

           |

           |

           +–System.NotImplementedException  

           |

           |

           +–System.NotSupportedException  

           |

           |

           +–System.NullReferenceException  

           |

           |

           +–System.OutOfMemoryException  

           |

           |

           +–System.RankException  

           |

           |

           +–System.Security.SecurityException  

           |

           |

           +–System.Security.VerificationException  

           |

           |

           +–System.StackOverflowException  

           |

           |

           +–System.Threading.SynchronizationLockException  

           |

           |

           +–System.Threading.ThreadAbortException  

           |

           |

           +–System.Threading.ThreadStateException  

           |

           |

           +–System.TypeInitializationException  

           |

           |

           +–System.UnauthorizedAccessException  

 

Comments (18)

  1. Uwe Keim says:

    Cool. I’m sure there is a tool to create those textual class diagrams?!?

  2. Yes, I wrote it back when we did vol1 of the SLAR… It is very messy code, so I don’t want to post it as-is… Maybe i’ll look into cleaning it up..

  3. sbjorg says:

    I said it while at MS and I’ll say it again, having this much exceptions is overkill. You should differentiate b/w exceptions that make sense being caught during runtime and exceptions that exist purely for informational purposes during debugging. For instance, why would I want to programmatically distinguish among the different kinds of arithmetic exceptions? Why do you feel justified burdening developers with this cognitive burden? To what gain?

  4. . says:

    Aren’t you supposed to descend from ApplicationException for your own exceptions?

  5. Ifeanyi Echeruo says:

    sbjorg: "or instance, why would I want to programmatically distinguish among the different kinds of arithmetic exceptions?"

    I dont understand what’s so hard about

    try {



    }

    catch(System.ArithmeticException e) {



    }

  6. Kevin Westhead says:

    Deriving from ApplicationException was the original advice offered, but that guideline will be changing (FxCop has already changed to reflect the new thinking). It seems that the original idea was to offer the ability to group framework exceptions (those that derive from SystemException) and non-framework exceptions (those that derive from ApplicationException), however your non-framework exceptions may as well be derived from Exception since ApplicationException just adds an extra level of depth to the hierarchy.

  7. Looks like Krzysztof just published some great info on .NET exceptions: http://blogs.msdn.com/kcwalina/archive/2005/03/16/396787.aspx

  8. Jeff Atwood says:

    I have a little code sample that iterates through all .NET classes and then sorts/lists all the ones that end in "Exception" here:

    http://www.codinghorror.com/blog/archives/000115.html

  9. Igor Brejc says:

    Thanks for the list, it is just what I was searching for in MSDN docs few days ago, but didn’t find it :).

    One comment though: If you re-use certain existing exceptions (NullReferenceException is one example), FxCop will give you a warning about non-compliancy with MS design guidelines. Those exceptions are meant to be thrown by runtime only, and not by user applications.

    Maybe you could include this information individualy for each exception type in the exception hierarchy?

  10. Here is a tool you can use to get the exception hierarchy with assembly information:

    http://spaces.msn.com/members/cnasarre/Blog/cns!1pmtDU_7A3ODVjdKP4wqJqkg!212.entry

  11. David Levine says:

    There are many other exceptions defined in mscorlib.dll then the ones listed. In addition to the other points, e.g. FxCop complaining about using some of the exception types, some other points on the exceptions listed…

    ThreadAbortException does not offer any of the standard constructors .ctor(), .ctor(string message) or .ctor(string message,Exception inner). This only matters because it means that you cannot create your own instance of this exception, so you cannot directly throw it, you should use the Thread.Abort() API. I don’t think it should be included in the list of exceptions that applications should be directly throwing.

    I don’t believe applications should be throwing ExecutionEngineException, StackOverflowException, or OutOfMemoryExceptions. In earlier versions of the runtime throwing any of these caused occasional strange results with the runtime (such as it shutting down). I also cannot think of a good reason why an application would be correct in throwing one of these.

    ObjectDisposedException and TypeInitializationException do not have a default constructor, so serializing them across a machine boundary might cause problems. I would test this before doing so.

    Some minor observations…

    ArgumentNullException, ArgumentOutOfRangeException, DuplicateWaitObjectException,

    ObjectDisposedException do not offer the standard .ctor(string message,Exception inner)

    constructor. This isn’t really a problem but it is non-standard.

    System.NotFiniteNumberException, SecurityException, and TypeInitializationException do not override the Message property to offer a better exception message. Again, minor, but there seems to be little value in a special exception if it does not provide additional clarification.

  12. Keith Hill says:

    "I don’t believe applications should be throwing ExecutionEngineException, StackOverflowException, or OutOfMemoryExceptions."

    +1 for that (except for injecting errors for testing). I would also add NullReferenceException to that list and perhaps even InvalidCastException.

  13. Ivara blogs says:

    Šodien   Vakar Andrejs jau aizskāra tēmu, par kuru es jau pasen gribu uzrakstīt, bet kaut kā