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
Anonymous
March 27, 2005
Cool. I'm sure there is a tool to create those textual class diagrams?!?Anonymous
March 27, 2005
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..Anonymous
March 27, 2005
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?Anonymous
March 28, 2005
Aren't you supposed to descend from ApplicationException for your own exceptions?Anonymous
March 28, 2005
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) {
...
}Anonymous
March 28, 2005
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.Anonymous
March 28, 2005
Looks like Krzysztof just published some great info on .NET exceptions: http://blogs.msdn.com/kcwalina/archive/2005/03/16/396787.aspxAnonymous
March 28, 2005
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.htmlAnonymous
March 28, 2005
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?Anonymous
March 28, 2005
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.entryAnonymous
March 28, 2005
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.Anonymous
March 29, 2005
"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.Anonymous
January 09, 2008
Šodien   Vakar Andrejs jau aizskāra tēmu, par kuru es jau pasen gribu uzrakstīt, bet kaut kāAnonymous
March 25, 2008
PingBack from http://blog.todobom.dk/post/Liste-over-exceptions-i-NET.aspxAnonymous
August 02, 2008
PingBack from http://abbie.getyourfreefitnessvideo.info/exceptiontype13.htmlAnonymous
March 21, 2009
PingBack from http://www.is34.net/guncel-notlar.html