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.Exception whenever possible; try to catch just the
specific errors that are specific to that block of code. Catch
System.IO.FileNotFound instead."

Can someone elaborate on this?

Thanks in advance!

 

[Michael Nemtsev]

Hello pack,

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

AppDomain.CurrentDomain.UnhandledException handing

p> "Always try to catch specific exceptions.
p>
p> Avoid catching System.Exception whenever possible; try to catch just
p> the specific errors that are specific to that block of code. Catch
p> System.IO.FileNotFound instead."
p>
p> Can 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]

Hi,

What's "global exception handler"?

An event handler attached to the AppDomain.UnhandledException 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.Exception whenever possible; try to catch just the
specific errors that are specific to that block of code. Catch
System.IO.FileNotFound instead."

Can someone elaborate on this?

If you know a method might throw FileNotFoundException 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 FileNotFoundException. 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
FileNotFoundException due to concurrency issues, so you should still use try..catch in this case.
Then, FileNotFoundException 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 OutOfMemoryException, StackOverflowException and
ExecutionEngineException 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 "constrained execution regions", for example)

Other exceptions such as ArgumentNullException 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.