Question about exception handling best practice

  • Thread starter Thread starter csharper
  • Start date Start date
C

csharper

I've learned quite a few best practice rules for exception handling
from

http://www.codeproject.com/KB/architecture/exceptionbestpractices.aspx

My question here isn't addressed in that article. I know that
catching a generic Exception is not recommended. But what about
catching nothing like so?

try
{
// code that may throw exceptions
}
catch // since catch(Exception ex) is not recommended, right?
{
myLogger.Debug("Some error has occurred.");
}

I ask because

1) I really don't know what exception maybe thrown from the existing
code snippet,

2) Yet, I do need to log the error if it does happen.

What would you do?
 
csharper said:
I've learned quite a few best practice rules for exception handling
from

http://www.codeproject.com/KB/architecture/exceptionbestpractices.aspx

My question here isn't addressed in that article. I know that
catching a generic Exception is not recommended. But what about
catching nothing like so?

try
{
// code that may throw exceptions
}
catch // since catch(Exception ex) is not recommended, right?
{
myLogger.Debug("Some error has occurred.");
}

I ask because

1) I really don't know what exception maybe thrown from the existing
code snippet,

2) Yet, I do need to log the error if it does happen.

What would you do?
Click to expand...

Personally, I usually do capture the Exception object as I normally would want
to log the exception text and stack trace rather than just "some error".

I'm unclear why anyone would say that capturing less information would somehow
be a better practice. I tend to doubt that that is what the article you
reference is trying to suggest. Probably they are advocating capturing specific
expected exceptions only, otherwise let the exception bubble up. Which is fine
if you have identified any such specific error cases, but at some level in your
app you may well be want an error handler which deals with recovering from
unexpected errors. At that point the more forensic information you have logged
the better, IMO.

-rick-
 
Personally, I usually do capture the Exception object as I normally wouldwant
to log the exception text and stack trace rather than just "some error".

I'm unclear why anyone would say that capturing less information would somehow
be a better practice.  I tend to doubt that that is what the article you
reference is trying to suggest.  Probably they are advocating capturingspecific
expected exceptions only, otherwise let the exception bubble up.  Whichis fine
if you have identified any such specific error cases, but at some level in your
app you may well be want an error handler which deals with recovering from
unexpected errors.  At that point the more forensic information you have logged
the better, IMO.

-rick-
Click to expand...

As I read your response a few times, it sounds to me that you have
misunderstood my question. Are you saying that I meant catching
nothing (as in catch {}) is better practice than catching a generic
exception (as in catch (Exception exception) {})?

From what I heard and read, it seems that catching a generic exception
like

try
{
}
catch (Exception ex)
{
}

is not considered good practice.

and I simply don't know if it is good or bad to catch nothing as in

tr
{
}
catch
{
}

Actually I don't know if if catch { } is the same as catch (Exception
exception) { }.
 
Part of using rules is knowing when they don't apply.

In the case of catching exceptions, you should catch only those
exceptions that you expect and know exactly how to handle them.  In many
cases, this really does mean you shouldn't be catching all exceptions,
and should be using a more specific Exception sub-class.

But, at the highest level of a given program thread, it may well be that
you need to deal with every exception.  Logging errors is a classic
example.  Even if all you do after is terminate processing, you still
want to know an error happened.

Unfortunately, FxCop still hasn't figured this out.  So I wind up with
exclusion rules at these kinds of code sites where the base Exception
class needs to be caught.  :(

Pete
Click to expand...

So, from what you say, for my situation where I do want to log the
exception, but I really don't know what kind of concrete exception it
may throw, I still have to catch (Exception exception) and log it. Am
I understanding your points? Thanks.
 
I've learned quite a few best practice rules for exception handling
from

http://www.codeproject.com/KB/architecture/exceptionbestpractices.aspx
Click to expand...

Nice article.
My question here isn't addressed in that article. I know that
catching a generic Exception is not recommended. But what about
catching nothing like so?
Click to expand...

I think it's means catch _anything_. Although C# and VB.Net only allow
to throw exception-based exception, certain languages (C++/CLI for
example) does allow to throw anything (int, string, etc).
try
{
// code that may throw exceptions
}
catch // since catch(Exception ex) is not recommended, right?
{
myLogger.Debug("Some error has occurred.");
}
Click to expand...

I think it is basically the same as catch(Exception ex). I had tried
below code,

try
{
// throw something
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
catch
{
Console.WriteLine("Anything was thrown");
}

And the compiler emit a warning:

A previous catch clause already catches all exceptions. All
non-exceptions thrown will be wrapped in a
System.Runtime.CompilerServices.RuntimeWrappedException.
I ask because

1) I really don't know what exception maybe thrown from the existing
code snippet,

2) Yet, I do need to log the error if it does happen.
Click to expand...

As Pete had noted, sometimes it make sense to catch unhandled exception
for logging purpose, but make sure you throw it back.

Regards.
 
Nice article.


I think it's means catch _anything_. Although C# and VB.Net only allow
to throw exception-based exception, certain languages (C++/CLI for
example) does allow to throw anything (int, string, etc).


I think it is basically the same as catch(Exception ex). I had tried
below code,

   try
   {
     // throw something
   }
   catch (Exception ex)
   {
     Console.WriteLine(ex.Message);
   }
   catch
   {
     Console.WriteLine("Anything was thrown");
   }

And the compiler emit a warning:

A previous catch clause already catches all exceptions. All
non-exceptions thrown will be wrapped in a
System.Runtime.CompilerServices.RuntimeWrappedException.        




As Pete had noted, sometimes it make sense to catch unhandled exception
for logging purpose, but make sure you throw it back.

Regards.
Click to expand...

Good point. It is very important to add

throw;

right after the logger.Debug call.

If you don't tell me so, I might simply logger.Debug and swallow it
silently. Thanks.
 
csharper said:
As I read your response a few times, it sounds to me that you have
misunderstood my question. Are you saying that I meant catching
nothing (as in catch {}) is better practice than catching a generic
exception (as in catch (Exception exception) {})?

From what I heard and read, it seems that catching a generic exception
like

try
{
}
catch (Exception ex)
{
}

is not considered good practice.

and I simply don't know if it is good or bad to catch nothing as in

tr
{
}
catch
{
}

Actually I don't know if if catch { } is the same as catch (Exception
exception) { }.
Click to expand...

They are the same, AFAIK, except that in the one case you have access to the
Exception object and in the other you don't.

What I'm saying is that I see very little difference between catching Exception
ex and catching nothing except that in the latter case you have less information
to help debug your app from your error log.

I haven't read the article you refernce. But I will go out on a limb here and
guess that whoever is telling you that catch (Exception ex) is bad would tell
you also that catch nothing is bad too and for the same reason, whatever it is.
I do understand that to have been the thrust of your actual question.

Personally I think that catching nothing is almost completely useless except
maybe for people who can't find a bug in some routine and hope instead that
ignoring it will make everything okay. It is usually a horrible practice, at
least as often used.

Whereas I think that catching the generic Exceoption object for logging/forensic
purposes can be a valid and useful thing to do sometimes. For one thing it can
help you identify those non-generic errors which you might prefer to handle with
a custom catch block. SQL timeout might be an example of this. It's not
necessarily a bug in your app, but you may have some action to take if it
happens. You may never know that is what's happening if you just log "some
error" and then continue as if nothing had happened.


-rick-
 
I've learned quite a few best practice rules for exception handling
from

http://www.codeproject.com/KB/architecture/exceptionbestpractices.aspx

My question here isn't addressed in that article.  I know that
catching a generic Exception is not recommended.  But what about
catching nothing like so?

try
{
   // code that may throw exceptions}

catch // since catch(Exception ex) is not recommended, right?
{
   myLogger.Debug("Some error has occurred.");

}

I ask because

1) I really don't know what exception maybe thrown from the existing
code snippet,

2) Yet, I do need to log the error if it does happen.

What would you do?
Click to expand...

I'd use one central global error handler for the majority of error
handling.

I put try catches around code where I know there's likely to be an
error and I want to alter processing flow if there is.
For example if I'm writing something which communicates with a third
party server I know that's going to occasionally time out.
When it does I'll want to try and connect again and if that fails tell
the user I can't connect and he should try again, maybe later.

So if you saw most of my code, there's no try catches.
 
Back
Top