Try Catch Overkill

[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.

[fallenidol]

you should never have another try block within a catch block

"pigeonrandle" <pi**********@hotmail.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.com...

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.

[pigeonrandle]

Hi,
Surely exceptions can occur in catch blocks? And what is a man to do if
this happens?!

Cheers,
James.

fallenidol wrote:

you should never have another try block within a catch block

"pigeonrandle" <pi**********@hotmail.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.com...

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.

[Adam Clauss]

"fallenidol" <fa********@discussions.microsoft.comwrote in message
news:e3**************@TK2MSFTNGP03.phx.gbl...

you should never have another try block within a catch block

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 Clauss

[Jack Robertson]

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)

"pigeonrandle" <pi**********@hotmail.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.com...

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.

[pigeonrandle]

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.

Jack Robertson wrote:

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)

"pigeonrandle" <pi**********@hotmail.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.com...

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.

[Mythran]

"pigeonrandle" <pi**********@hotmail.comwrote in message
news:11**********************@m7g2000cwm.googlegro ups.com...

Hi,
Surely exceptions can occur in catch blocks? And what is a man to do if
this happens?!

Cheers,
James.

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

[pigeonrandle]

Mythran,

Thanks for your reply. And yes, it does help!

James.

Mythran wrote:

"pigeonrandle" <pi**********@hotmail.comwrote in message
news:11**********************@m7g2000cwm.googlegro ups.com...

Hi,
Surely exceptions can occur in catch blocks? And what is a man to do if
this happens?!

Cheers,
James.

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

[Michael C]

"Jack Robertson" <no_spam@_nospam.comwrote in message
news:ue**************@TK2MSFTNGP05.phx.gbl...

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.

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

Michael

[Michael C]

"pigeonrandle" <pi**********@hotmail.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.com...

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

Please don't multipost.

[pigeonrandle]

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

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

James.

Michael C wrote:

"pigeonrandle" <pi**********@hotmail.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.com...

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

Please don't multipost.

[Cor Ligthert [MVP]]

See my answer in another newsgroup where you have posted this

Cor

"pigeonrandle" <pi**********@hotmail.comschreef in bericht
news:11*********************@b28g2000cwb.googlegro ups.com...

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.

[pigeonrandle]

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

cheers,
James.

Cor Ligthert [MVP] wrote:

See my answer in another newsgroup where you have posted this

Cor

"pigeonrandle" <pi**********@hotmail.comschreef in bericht
news:11*********************@b28g2000cwb.googlegro ups.com...

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.

[fallenidol]

....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.
--
"If ignorance is bliss, then wipe the smile from my face."
"Adam Clauss" wrote:

"fallenidol" <fa********@discussions.microsoft.comwrote in message
news:e3**************@TK2MSFTNGP03.phx.gbl...

you should never have another try block within a catch block

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 Clauss

[Martin Carpella]

fallenidol <fa********@discussions.microsoft.comwrites:

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.

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

[fallenidol]

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.
--
"If ignorance is bliss, then wipe the smile from my face."
"Martin Carpella" wrote:

fallenidol <fa********@discussions.microsoft.comwrites:

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.

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

[Chris Dunaway]

On Nov 1, 6:44 am, fallenidol <[e-mail]>
wrote:

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.

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.

[Martin Carpella]

fallenidol <fa********@discussions.microsoft.comwrites:

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.

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

[Cor Ligthert [MVP]]

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" <pi**********@hotmail.comschreef in bericht
news:11**********************@f16g2000cwb.googlegr oups.com...

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

cheers,
James.

Cor Ligthert [MVP] wrote:

>See my answer in another newsgroup where you have posted this

Cor

"pigeonrandle" <pi**********@hotmail.comschreef in bericht
news:11*********************@b28g2000cwb.googlegr oups.com...

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.

[Bruce Wood]

pigeonrandle wrote:

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?

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. :-)

[Jon Skeet [C# MVP]]

fallenidol <fa********@discussions.microsoft.comwrote:

throwing and catching exceptions is expensive and so should be avoided

Throwing exceptions isn't *that* expensive - not when it should only
happen on error (i.e. rarely) and that error should usually go high
enough up to stop the code from retrying over and over again.

See http://www.pobox.com/~skeet/csharp/exceptions.html for the myth of
the expensive exception.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Cor Ligthert [MVP]]

Jon,

Although you are right, is the unnecessary use of a try catch block at least
not good maintenable.
(A global catch can in my idea only be used if you are not sure of the
quality of your code).

I know that you did not write this to promote to use everywhere try and
catch block, but before somebody would understand that from your message.

Cor

"Jon Skeet [C# MVP]" <sk***@pobox.comschreef in bericht
news:MP***********************@msnews.microsoft.co m...

fallenidol <fa********@discussions.microsoft.comwrote:

>throwing and catching exceptions is expensive and so should be avoided

Throwing exceptions isn't *that* expensive - not when it should only
happen on error (i.e. rarely) and that error should usually go high
enough up to stop the code from retrying over and over again.

See http://www.pobox.com/~skeet/csharp/exceptions.html for the myth of
the expensive exception.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Cor Ligthert [MVP]]

Bruce,

I don't agree with you about the try catch inside a try catch.

If you are not sure that there is a database server connected in some
situation (take by instance over the Internet) than I like to use a try
catch for that.

Inside that try catch block comes than a the normal processing with a try
catch block by instance for as that server goes ofline or any other error.

There are plenty of other situations like this.

Just my idea,

Cor

"Bruce Wood" <br*******@canada.comschreef in bericht
news:11**********************@h48g2000cwc.googlegr oups.com...

>
pigeonrandle wrote:

>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?

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. :-)

[pigeonrandle]

Hi,

Is it me or is this like the whole 'goto' argument all over again?! If
you declare uninitialised variables outside the try ... catch, then you
have to option of using 'serial' try ... catch blocks, as opposed to
nested ones since the variables are always in scope.

Cheers all,
James.

Cor Ligthert [MVP] wrote:

Bruce,

I don't agree with you about the try catch inside a try catch.

If you are not sure that there is a database server connected in some
situation (take by instance over the Internet) than I like to use a try
catch for that.

Inside that try catch block comes than a the normal processing with a try
catch block by instance for as that server goes ofline or any other error.

There are plenty of other situations like this.

Just my idea,

Cor

"Bruce Wood" <br*******@canada.comschreef in bericht
news:11**********************@h48g2000cwc.googlegr oups.com...

pigeonrandle wrote:

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?

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. :-)