Amazon.com Widgets

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  

 

Published 27 March 05 09:04 by BradA

Comments

# Uwe Keim said on March 27, 2005 9:57 PM:
Cool. I'm sure there is a tool to create those textual class diagrams?!?
# Brad Abrams [MSFT] said on March 27, 2005 10:07 PM:
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..
# sbjorg said on March 28, 2005 1:10 AM:
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?
# . said on March 28, 2005 11:40 AM:
Aren't you supposed to descend from ApplicationException for your own exceptions?
# Ifeanyi Echeruo said on March 28, 2005 1:25 PM:
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) {
...
}
# Kevin Westhead said on March 28, 2005 1:35 PM:
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.
# Judah Himango said on March 28, 2005 6:13 PM:
Looks like Krzysztof just published some great info on .NET exceptions: http://blogs.msdn.com/kcwalina/archive/2005/03/16/396787.aspx
# Jeff Atwood said on March 28, 2005 10:04 PM:
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
# Igor Brejc said on March 29, 2005 12:45 AM:
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?
# Christophe Nasarre said on March 29, 2005 3:17 AM:
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
# David Levine said on March 29, 2005 5:30 AM:
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.


# Jesse Squire's Weblog said on March 29, 2005 8:35 AM:
# Keith Hill said on March 29, 2005 9:08 AM:
"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.
# Jesse Squire's Weblog said on June 23, 2005 5:52 AM:
# Ivara blogs said on January 9, 2008 7:19 PM:

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

# Liste over exceptions i .NET said on March 26, 2008 6:11 AM:

PingBack from http://blog.todobom.dk/post/Liste-over-exceptions-i-NET.aspx

# exception type 13 said on August 2, 2008 5:56 PM:

PingBack from http://abbie.getyourfreefitnessvideo.info/exceptiontype13.html

# iS34.Net G??ncel Haberler » G??ncel Notlar said on March 21, 2009 3:07 PM:

PingBack from http://www.is34.net/guncel-notlar.html

New Comments to this post are disabled

Search

This Blog

Syndication

Page view tracker