Exception handling

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Say I've created a piece of code that involves both sql, io and some number
conversions. Being a responsible developer I have tried to catch all of the
exceptions - but how can I be sure?

Is there a way to list exactly which exceptions that are not handlet?
(design time)

I could of cause ... use catch (Exception e) {...} as the final catch ...
but I would prefer to now the "landscape" before doing that ..

regards Jesper
 
Jesper,

No routine should catch all exceptions -- only those that it is responsible
for handling. Others should bubble up to be handled as appropriate by
callers. Somewhere at the top of your calling tree -- perhaps in Main() --
you catch all the unhandled exceptions, which would be fatal errors, and
display or log them as appropriate.

In a non-trivial method call which may itself call other methods, there is
an infinitude of possible exceptions that might come back at you. It's a
losing battle to handle everything concievable.

Java and a few other languages provide "checked exceptions" where you define
all the exceptions a method might throw and are then forced to implement
handlers for each exception type. The architects of C# decided against
this. The subject has been beaten to death in the past so I won't go into
it here; if interested, Google on:

"checked exceptions" C#

--Bob

"Jesper Ordrup Christensen"
 
Hi Bob and thanks for answering,

I'm aware of the "subjectbeating" and I promise that I'm not going to into
that ..

I agree completly with your comments and I'm not trying to create a monster
execption handling routine that deals with every possible exception. But I
would very much like to be aware of which execptions could be thrown and
thereby being much more able to decide which ones that should bubble and
which ones that should be handled right away.

Its not checked exceptions im after its more like intellisence ... and an
exellent way of implementing it could be if all relevant exceptions where
shown when I was typing the catch() part ...

Anything beats traversing all the framework documentation ... but what ??

Regards

Jesper
 
Hi Jesper,

I'm not sure how the compiler or the IDE would know what exceptions would be
relevant. The designer usually has an idea. For example if you are talking
to the database you would anticipate an SqlException as the most likely to
arise, and the most appropriate to handle locally. If you are talking to
potentially different back ends you might have to handle OleDbException,
OracleException, OdbcException and so on. Perhaps one might add
DataException. Even when you know that a broad class of exceptions are
likely, it isn't necessarily true that you would want to handle them. Most
exceptions are fatal anyway, and need to be debugged out.

Exceptions by their nature are ... well, exceptional. They seldom are
something I can just correct or ignore, and even when they are, I try to
find alternatives because catching an exception is expensive in terms of
performance. So for instance, testing if a file exists first is better than
handling a possible FileNotFoundException.

So as long as an exception is caught and logged and the app shuts down
gracefully (backing out DB transactions and closing unmanaged resources and
the like) I'm happy. So rather than worry about catching exceptions I worry
about whether a code section is critical (requiring logic for graceful
failure) or whether an exception at that point would be adequately logged
for later diagnosis, and I catch exceptions on that basis.

Often it doesn't matter that much what kind of exception it is so long as
it's properly handled. "catch (Exception)" is often plenty fine for that.

I seldom have more than one catch block in a method, and I don't remember
the last time I had more than 2. And I suppose that fully 80% of my methods
have no exception handling at all. Am I just strange that way? I'm curious
what others have in their completed projects in this regard.

--Bob

"Jesper Ordrup Christensen"
 
"Jesper Ordrup Christensen"
Hi Bob and thanks for answering,

I'm aware of the "subjectbeating" and I promise that I'm not going to into
that ..

I agree completly with your comments and I'm not trying to create a monster
execption handling routine that deals with every possible exception.
Click to expand...

I've come to use the following strategy...

If I know of a specific exception that I can recover from or that needs
special processing I catch the specific exception...this may involve
wrapping and rethrowing the original exception. If I have concluded that I
cannot catch a specific exception but there is useful context that can be
added that will aid in trouble-shooting/analysis, then I catch the general
exception, add context information (wrap it in a new exception), and throw
that.

At a logical or physical boundary I log it and decide whether to allow it to
propagate further or map it to some other error indicating mechanism.

At some high level there often isn't much to do other then present the
information, and perhaps allow the user to retry it. I usually don't just
terminate the application, but this should be decided on a per-app basis.


But I
would very much like to be aware of which execptions could be thrown and
thereby being much more able to decide which ones that should bubble and
which ones that should be handled right away.
Click to expand...

There isn't anything in the current version of DevStudio or the runtime to
help with this. Right now your only option is to refer to the documenation
for the list of exceptions that can be thrown, and even there I would take
it with a grain of salt. Typically what is documented are the exceptions
that the called routine itself throws, but it does not document the
exceptions that might be thrown by other routines that are invoked
internally. So a routine might throw a SQL-type exception, and it may also
throw a NullReferenceException if a support method that it calls might
throw. I would take the documented list as a minimum list of exceptions, not
a complete list.

Its not checked exceptions im after its more like intellisence ... and an
exellent way of implementing it could be if all relevant exceptions where
shown when I was typing the catch() part ...

Anything beats traversing all the framework documentation ... but what ??
Click to expand...

I've been assured there's work being done on this. It should get better in
future releases but there's still a lot of work that needs to be done. This
is a subject that's been discussed many times.
 
Jesper,
In addition to the other comments.

What are you planning on doing with the Exception?

I find it better to not catch exceptions unless there is something specific
I am going to do with it. For example catching the FileNotFound exception to
allow the user to try a different file. While logging the exception is
normally not specific enough for me to catch inline.

Rather I simply let exceptions float up to the Global Exception Handlers,
where I do any exception logging. However! I will use Try/Finally & the
Using statement to clean up any resources (call the Dispose methods).

In other words I favor Try/Finally (good) over Try/Catch (not as good). I
use Try/Catch where I have something specific to do with that specific
exception.


See the MSDN Mag article below for details.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your app, as
well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why & when you
use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/issues/04/06/NET/default.aspx

For example: In my Windows Forms apps I would have a handler attached to the
Application.ThreadException event, plus a Try/Catch in my Main. The
Try/Catch in Main only catches exceptions if the constructor of the MainForm
raises an exception, the Application.ThreadException handler will catch all
uncaught exceptions from any form/control event handlers.

Hope this helps
Jay


"Jesper Ordrup Christensen"
 
Jay B. Harlow said:
Jesper,
In addition to the other comments.

What are you planning on doing with the Exception?

I find it better to not catch exceptions unless there is something specific
I am going to do with it. For example catching the FileNotFound exception to
allow the user to try a different file. While logging the exception is
normally not specific enough for me to catch inline.

Rather I simply let exceptions float up to the Global Exception Handlers,
where I do any exception logging. However! I will use Try/Finally & the
Using statement to clean up any resources (call the Dispose methods).
Click to expand...


I totally agree with this. It is very good guidance and should be
considered a best practice.

Joe
 
Back
Top