Questions about an article

[pack]

"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!

[Michael Nemtsev]

Re: Questions about an article

Hello pack,

p"Unless you have a very good reason to catch an exception, DON'T.
pExceptions are supposed to be exceptional, just like the dictionary
pmeaning: uncommon, unusual. When in doubt, let the calling routine,
por the global exception handler, deal with it. This is the golden
prule. The hardest kinds of exceptions to troubleshoot are the ones
pthat don't even exist, because a developer upstream of you decided to
pconsume it."
p>
pWhat's "global exception handler"?

AppDomain.Curre ntDomain.Unhand ledException handing

p"Always try to catch specific exceptions.
p>
pAvoid catching System.Exceptio n whenever possible; try to catch just
pthe specific errors that are specific to that block of code. Catch
pSystem.IO.File NotFound instead."
p>
pCan someone elaborate on this?

This mean that you need to catch only what do u expect to manage in this
concrete situation and leave other errors to its own to don't miss other
errors that u expect to catch in other places

---
WBR,
Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

[Dave Sexton]

Re: Questions about an article

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" <packgr@comcast .netwrote in message news:%23G$0RHAD HHA.996@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!
>
>