exception

[frazer]

1 when i get an error in my code where the error is not handled,
all i get is a system error, i dont get detailed information that i get when
the code is in a try catch block.
how do i get that info at runtime without having to add a try catch block.

2 also how do i handle exceptions at one place. or do i have to write try
catch everywhere?


thanx

 

[William Ryan eMVP]

1 when i get an error in my code where the error is not handled,
all i get is a system error, i dont get detailed information that i get when
the code is in a try catch block.
how do i get that info at runtime without having to add a try catch block

Why wouldn't you want to use a try catch block? You don't need every
function wrapped, but the callers of functions should have them..

2 also how do i handle exceptions at one place. or do i have to write try
catch everywhere?

Don't do this... you may want some top level handlers but Exception handlers
are there to allow you to respond effectively to problems, many of which you
can't control. There are sooo many things that can go wrong that generic
handlers are really terrible if you aren't using specific ones. You don't
need try catches everywhere, you can let the exception propogate up, but you
should probably use them in most places and rethrow them.... an IOException
is totally different beast then SqlException caused by a timeout...so how
could one handler effectively handle them both unless it's basically just
eating it?

Not trying to lecture but what you are asking is really a recipe for
trouble.. I'd highly recommend reading up on this so you truly understand
why this is a really bad practice
http://msdn.microsoft.com/theshow/Episode008/Richter.html

There are tons of examples out there but you really should only catch stuff
you are expecting and Respond to it with your handler. Or throw it uup the
stack for someone else to handle. but don't just eat it and treat all
exceptions like they are the same, they are very very different.

HTH,

Bill

 

[Bruno Jouhier [MVP]]

There are usually a few "strategic" places in your code where you should put
a try / catch that catches all exceptions, reports them in a friendly way to
the user and logs all the details. Usually these places are high in the call
stack: event loop, event handlers, etc.

But don't put try/catch in every method, your code will become a mess,
exceptions will be logged and reported several times, or thrown away, etc.

Also, the framework is usually setting up a default handler that reports the
exception to the user for you. Unfortunately, it does not always give the
level of friendliness that you would like, and it does not log the exception
details anywhere. But it sends an event that you can trap. So, take a look
at the Application.ThreadException event if you are writing a WinForms
application (warning: this event does not work when your process is attached
to the debugger, but it works when the process runs on its own).

Also, there was another reply saying that catching all exceptions is a bad
idea. I will say the exact opposite: catching all exceptions and treating
them all the same is the cleanest way to do exception handling. It really
means that you use exceptions to signal exceptional events, and that you use
"normal" mechanisms (return values, if/then/else tests) for all the special
conditions that you have analyzed and decided to handle. I think that this
distinction between "special" (conditions that you anticipated and decided
to handle because you have something special you can do about them) and
"exceptional" (conditions that you did not anticipate or did not want to
handle in a special way) is a very important design decision, and (this is
were some other people won't agree) I think that "exceptional" conditions
should be signaled through exceptions but that "special" conditions should
be tested with "normal" constructs (return values, if/then/else). I've used
this approach in several large projects and it really works. So, don't feel
so bad about catching all exceptions (but catch them only in a few strategic
places - or wrap them into a higher level exception that you will rethrow so
that the final catchall will get both the low level details and some higher
level context information).

Bruno.