Try Catch Overkill

  • Thread starter Thread starter pigeonrandle
  • Start date Start date
P

pigeonrandle

Hi,
Does this bit of code represent complete overkill?!

try
{

//create a treenode
TreeNode tn = new TreeNode();
//add it to a treeview
tv.Nodes.Add(tn);
//do some other stuff

}
catch (Exception ee) //something weird has happened
{

try
{
//try to remove the treenode from the treeview
if (tn.TreeView != null) tn.Remove();
}
catch (Exception ee) //now things have got really dire
{
MessageBox.Show("Would a function like TreeNode.Remove() ever cause
a random exception that i should worry about?");
}

}

What i basically mean is ... if this situation arises then someone has
probably poured a cup of coffee into the computer so i won't have to
worry about my software/data being 'recoverable', or will this sort of
*hilarious* thing never happen?

Explanations, musings and criticism all welcome,
James Randle.
 
Hi,
Surely exceptions can occur in catch blocks? And what is a man to do if
this happens?!

Cheers,
James.
 
You can go crazy trying to catch all errors. In practice however, assuming
your program isn't of a truly critical nature (by that I mean someone's life
doesn't depend on it, nor does someone stand to lose a lot of money if it
fails), the cleanest approach is to simply put a try/catch in your top-level
functions and let these catch all unexpected errors. You can then log the
error, inform the user, or whatever is required all in one location (very
clean). For those errors that you do expect during normal processing however
(e.g., a file not found error for example), you can choose to handle these
on a case-by-case basis as you go along. Note that the definition of
"unexpected" is something you have to work out for your particular app (most
errors typically are however)
 
fallenidol said:
you should never have another try block within a catch block
Click to expand...

Oh really? And you are basing that on? What if your exception handling
calls another function that could potentially cause an exception? You
should just let it float all the way up to the OS?
 
Adam, Jack,

Thanks for your replies gentlemen.

I see what you mean about catching the errors at the top level. To be
honest i had forgotten that errors propagate up if there is an error
handler higher up the stack.
Fortunately, nobody's life is depending on my programming (thank
goodness). Of course, when i plug it into the ECG monitor things might
get a little hairy...

Cheers,
James.
 
pigeonrandle said:
Hi,
Surely exceptions can occur in catch blocks? And what is a man to do if
this happens?!

Cheers,
James.
Click to expand...


Yes, you can have try...catch within a catch block. If not, the compiler
would not allow it. What I would do though, is call a method from within
the catch block and have the method contain the next try...catch. This way,
it's easier to read.

Some exceptions are expected and unavoidable, specially when you are not the
author of third party assemblies. These exceptions can be expected to occur
when a specific situation occurs that you can't pre-check the values prior
to the method calls (values are generated within the assembly and are not
accessible).

For most situations, though, if you need a nested try...catch within a catch
block, check to see if there are ways to avoid it...

HTH,
Mythran
 
Jack Robertson said:
You can go crazy trying to catch all errors. In practice however, assuming
your program isn't of a truly critical nature (by that I mean someone's
life doesn't depend on it, nor does someone stand to lose a lot of money
if it fails), the cleanest approach is to simply put a try/catch in your
top-level functions and let these catch all unexpected errors.
Click to expand...

Have a look into the Application.ThreadException event, I suspect it will
save you a lot of coding :-)

Michael
 
Are you stalking me or something? Only joking :-)

Cheers for the hint, i have broken out my reading glasses.

James.
 
Cor,
Hi. I also posted this in the vb.net group, but can't find your post?

cheers,
James.
 
....so what do you do in the catch block of the nested try/catch? it can error
too...so you end up with infintely nested try/catch blocks.

in a try/catch block

you TRY something if it fails you CATCH it and do some error handling....the
error handling should deal with the error quickly and gracefully and shouldnt
need to raise any further error unless you specifically want to re throw the
error although this is best avoided.
 
fallenidol said:
you TRY something if it fails you CATCH it and do some error handling....the
error handling should deal with the error quickly and gracefully and shouldnt
need to raise any further error unless you specifically want to re throw the
error although this is best avoided.
Click to expand...

I can't follow this argument. Why wouldn't I want to rethrow an
exception, or why should I even try to avoid it?

In my experience it is quite often the case that you can recover only
partially from an error (i.e. maybe roll back a transaction in the DB
layer), but this handling does not "solve" the exception, so re-throwing
it after rolling back and/or logging the exception seems more than
appropriate to me in such scenarios.

And despite the fact that you cannot deal with the whole problem, there
can easily be exceptions in the error handling as well, e.g. logging
could fail.

Despite this, I well agree with your suggestion to move the code in the
catch-block to a separate method for increased readability in case of
nested try/catch or try/finally blocks.

Best regards,
Martin
 
throwing and catching exceptions is expensive and so should be avoided but
obviously there are times when you have to do it.

if you execute a method which say logs an error to a log file you would
probably want to put this exception into the event log as a "could not write
to error log" message rather than raise another exception within your catch
block.
 
you TRY something if it fails you CATCH it and do some error handling....the
error handling should deal with the error quickly and gracefully and shouldnt
need to raise any further error unless you specifically want to re throw the
error although this is best avoided.
Click to expand...

Why is it best avoided? You may wish to take some action in the catch
block, such as writing a log message to a file but still want to bubble
the exception up the call stack, perhaps to the UI so an error message
can be displayed to the user. You might wish to take the exception
that was thrown and wrap it in your own custom exception class through
the InnerException property but provide a custom Message and then throw
that. I guess, technically, that's not re-throwing the same exception,
though.
 
fallenidol said:
throwing and catching exceptions is expensive and so should be avoided but
obviously there are times when you have to do it.

if you execute a method which say logs an error to a log file you would
probably want to put this exception into the event log as a "could not write
to error log" message rather than raise another exception within your catch
block.
Click to expand...

I agree that raising exceptions is expensive, but re-throwing one
shouldn't be (i.e. just "throw;"). Hmm, well, you could be right, as
this still builds up a new stacktrace... Hmm...

Well, one counterargument from my side still left: assuming that the
original exception was really an "exception" (and not the common case),
I'd say the overhead cost of re-throwing the exception once or twice up
the chain before the ultimate handling of the exception is not an
overhead I'd really worry about.

Best regards,
Martin
 
I saw it, basicly my answer was

You should not use a catch if you can use an If or switch

You should only use a catch if you are sure that there can be an error be
throwed in the routine. In this case there can be null/nothing situation,
but that gives at least the idea that you most problaly do not very well
know what the project is doing.

Just my opinion,

Cor
 
pigeonrandle said:
Hi,
Does this bit of code represent complete overkill?!

try
{

//create a treenode
TreeNode tn = new TreeNode();
//add it to a treeview
tv.Nodes.Add(tn);
//do some other stuff

}
catch (Exception ee) //something weird has happened
{

try
{
//try to remove the treenode from the treeview
if (tn.TreeView != null) tn.Remove();
}
catch (Exception ee) //now things have got really dire
{
MessageBox.Show("Would a function like TreeNode.Remove() ever cause
a random exception that i should worry about?");
}

}

What i basically mean is ... if this situation arises then someone has
probably poured a cup of coffee into the computer so i won't have to
worry about my software/data being 'recoverable', or will this sort of
*hilarious* thing never happen?
Click to expand...

What no one has mentioned in this thread is that you should catch only
those exceptions with which you can do something useful.

It's not a question of whether a function throws an exception that you
"should worry about". Rather, it's a question of whether a function
throws an exception that you can do something about. If the answer is
that there is nothing you can do to resolve the situation, then let the
exception bubble up the stack and crash your program. (You should have
global exceptions registered via Application.ThreadException and
AppDomain.UnhandledException to log such errors.)

try...catch within catch is (and should be) a rare construct because
you shouldn't be catching many exceptions, period. Most exceptions mean
that your program is toast, that there's really nothing you can do to
recover.

In particular, you should avoid catch (Exception e) .... How often can
you really handle _any_ exception that could occur? How do you deal
gracefully with, for example, an OutOfMemoryException? Catch only what
you can handle, and let the rest go. (The only case in which I do catch
(Exception e) is when the documentation for a product is awful and
doesn't tell you what exceptions are possible. In situations like that
there may be no recourse but to catch them all. Crystal Reports comes
to mind.)

Anyway, there's lots more ranting in this newsgroup about exceptions,
when to catch them, and when not, including my own ranting. You can
search the history for much more blather. :-)
 
Back
Top