Hi,
<snip>
What's "global exception handler"?
An event handler attached to the AppDomain.Unhan dledException event, for instance. The event
handler should be registered when the application is started and it will catch all exceptions that
aren't caught higher in the call stack by try..catch blocks.
Avoid catching System.Exceptio n whenever possible; try to catch just the
specific errors that are specific to that block of code. Catch
System.IO.FileN otFound instead."
Can someone elaborate on this?
If you know a method might throw FileNotFoundExc eption and it can be gracefully handled in code
(i.e., there will be no state corruption and the application may move forward if the exception is
caught) then only catch FileNotFoundExc eption. By catching other exceptions you may inadvertently
hide a bug in your code or corrupt the state of your objects, creating different bugs.
In many cases you can alleviate this need by checking first if state or arguments required by the
method are valid before your code even attempts invocation. For instance, using File.Exists() can
be used to prevent File.OpenRead from being called within an invalid file path. This case isn't a
good example, particularly, because it's still possible for OpenRead to throw a
FileNotFoundExc eption due to concurrency issues, so you should still use try..catch in this case.
Then, FileNotFoundExc eption has even more meaning when its caught - The file was there when the code
checked for its existence, but it wasn't there when OpenRead was called (not that this extra
information will help you at all).
If you catch only Exception then exceptions such as OutOfMemoryExce ption, StackOverflowEx ception and
ExecutionEngine Exception will be caught as well. You probably don't want to swallow these since
they normally indicate that your code isn't designed properly, it contains a bug or there is a bug
in the framework. And you probably can't handle these gracefully anyway (without another exception
being thrown). The 2.0 framework has made considerable improvements over earlier framework versions
in how these exceptions can be handled so that the state of your application or a system's memory
isn't left in a corrupted state. (Search for "constraine d execution regions", for example)
Other exceptions such as ArgumentNullExc eption might indicate a bug in your code so you don't
necessarily want to catch that either in most cases. IMO you're always better off checking for null
first.
--
Dave Sexton
"pack" <pa****@comcast .netwrote in message news:%2******** *******@TK2MSFT NGP02.phx.gbl.. .
"Unless you have a very good reason to catch an exception, DON'T.
Exceptions are supposed to be exceptional, just like the dictionary meaning:
uncommon, unusual. When in doubt, let the calling routine, or the global
exception handler, deal with it. This is the golden rule. The hardest kinds
of exceptions to troubleshoot are the ones that don't even exist, because a
developer upstream of you decided to consume it."
What's "global exception handler"?
If DON'T catch an exception and let the calling routine to handle it, that
means my code still needs to handle it in the calling routine. So, what the
rule gives?
"Always try to catch specific exceptions.
Avoid catching System.Exceptio n whenever possible; try to catch just the
specific errors that are specific to that block of code. Catch
System.IO.FileN otFound instead."
Can someone elaborate on this?
Thanks in advance!
