Creating More Exceptional Exceptions

I find myself throwing plain old System.Exception far too often. If only I had a complete reference of the many default Exception classes Microsoft provides, like the one Chris Sully provides in his article. That's good as a starting point, but I don't see things like System.Data.DataException in there. Does anyone know of a more comprehensive list of *Exception classes for all the common .NET namespaces?


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2004/10/creating-more-exceptional-exceptions.html

If a findSomething(key) method throws an exception if ‘key’ is not found, this may cause a performance problem. Not finding something
should not be an exceptional condition in this case.

Jeff, why don’t you write something to reflect on the framework and compile a list of all the exceptions and post it?

Interesting post, particularly this snippet:

“You should not define new exception classes derived from ApplicationException; use Exception instead. In addition, you should not write code that catches ApplicationException”

I spent some time trying to find out the best ways to do exception handling a few months ago, and found this article on MSDN:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconBestPracticesForHandlingExceptions.asp

entitled ‘Best Practices for Handling Exceptions’ which states:

“Do not derive user-defined exceptions from the Exception base class. For most applications, derive custom exceptions from the ApplicationException class.”

I’m no power-coder, but these articles seem to contradict each other. This concerns me, especially as I have implemented the guidelines from the MSDN article in a lot of code already.

Any idea which one we should believe?

Because I’m lazy?

Andy,

There is conflicting advice on this issue. I have seen numerous credible sources say not to use Application Exception. I don’t know why that MSDN article has not been updated to reflect that advice though. I currently derive from ApplicationException as that seems to be the “official” position of MS at this point in time.

Jeff,

I thought it was a bad practice to “throw Exception”? I thought if your error condition did not fit one of the built-in exception types you were supposed to always throw a custom exception? That’s what I do anyway.

To All,

Writing proper exception handling is extremely difficult. Never underestimate the complexities involved. Every Java/.NET application I’ve taken over maintainence of has horrible exception handling that needs to be completely rewritten. That MSDN Best Practicies article Andy cited above is the best resource I’ve encountered thus far, but it is far from complete and an entire book could be written on this subject.

This will get worse before it gets better. Plenty of work for maintainance programmers going forward though.

“I thought it was a bad practice to “throw Exception”? I thought if your error condition did not fit one of the built-in exception types you were supposed to always throw a custom exception?”

Yes, that’s what I am saying-- I want to map my Throw System.Exception to a more specific built in *Exception, whichever one is the closest map. There’s no point in writing custom exception classes when an appropriate one already exists, after all. The problem is, I can’t find one single point of reference for all *Exception classes!

I actually find the structured exception handling very intuitive (and VASTLY superior), once I worked past the initial “Hey, where’s my crappy On Error Goto” mindset :wink:

Oh, and also, I think System.ApplicationException is a bad idea. I’ve always thought that, so I am siding with the “don’t use it, any other documentation is wrong” camp.

I hope this post is of some use:

http://www.dotnet247.com/247reference/msgs/4/24093.aspx

If you want to use wincv.exe, you can also find it here:

C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin\wincv.exe

www.dotnet247.com is a very useful site, by the way.

Regards,
Andy.

"Because I’m lazy?"
I love this comment, Jeff.
It’s the reason why programmers exist. People are lazy, and want somebody to help them do things automatically.

windchill:
""“If a findSomething(key) method throws an exception if ‘key’ is not found, this may cause a performance problem. Not finding something
should not be an exceptional condition in this case.”""

if instead of throwing an exception, it returned VB Nothing when key wasn’t found, wouldn’t that be impossible to differentiate from the situation where key’s value is intentionally VB Nothing?

this lookup should throw an error for this reason. if you don’t want to encounter an error here you should only call the function if a call to findSomething.has_key(key) is successful.

onektwenty4,

I agree that findSomething(key) should be conditional to findSomething.has_key(key). However, we need to be certain that when we throw an exception, we are not just throwing an error but an exceptional error. With the use of has_key(key), the lack of a key in the later call should be an exceptional error.

Everybody else,

Also, if you’re obeying the definition of an exception, the throwing of an exception should mean something terrible has happened and performance should not be a priority. What happened to the good ol’ days of C where we returned error codes and set errno?

Hmm, that last link seems to have gone essentially dead: it doesn’t 404, but redirects to http://blogs.msdn.com/ (exactly), which is perhaps worse.

It looks like it got moved to http://blogs.msdn.com/b/cbrumme/archive/2003/10/01/51524.aspx at some point, so I guess you should update the link?

The website that the link to Chris Sully’s article redirects to is serving viruses and infinite loop scare advertisement popups and should be removed ASAP.

1 Like