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?
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.
â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:
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.
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
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.
"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.
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?
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.