Try Catch Exception

[csharper]

I keep on reading about how bad it is to catch Exception instead of a more particular SomeKindOfException. But a method can potentially throw a dozen of concrete exceptions. Are we really supposed to chain a dozen catches like so?

try
{
SomeMethodThatThrowsDozensOfExeptions();
}
catch(Exception1 ex)
{
// handle it
}
catch(Exception2 ex)
{
// handle it
}
catch(Exception3 ex)
{
// handle it
}
catch(Exception4 ex)
{
// handle it
}
catch(Exception5 ex)
{
// handle it
}
catch(Exception6 ex)
{
// handle it
}
catch(Exception7 ex)
{
// handle it
}
....
catch(Exception_n ex)
{
// handle it
}

 

[Matt]

I keep on reading about how bad it is to catch Exception instead of a more particular SomeKindOfException.  But a method can potentially throw a dozen of concrete exceptions.  Are we really supposed to chain a dozen catches like so?

try
{
   SomeMethodThatThrowsDozensOfExeptions();}

catch(Exception1 ex)
{
  // handle it}

catch(Exception2 ex)
{
  // handle it}

<snip>

Realistically, if you are throwing that many exceptions, you are
probably not writing the method
in any kind of reasonable manner. Why would anything throw that kind
of exception number?

However, to go back to the issue, if you can handle the exception,
catch that type, do whatever
you need to do. If you can't, either re-throw it via catch or just
die, depending on what your needs
are.

Matt

 

[alex]

I keep on reading about how bad it is to catch Exception instead of a more particular

SomeKindOfException. But a method can potentially throw a dozen of concrete exceptions.

Are we really supposed to chain a dozen catches like so?

try
{
SomeMethodThatThrowsDozensOfExeptions();
}
catch(Exception1 ex)
{
// handle it
}
catch(Exception2 ex)
{
// handle it
}
catch(Exception3 ex)
{
// handle it
}
catch(Exception4 ex)
{
// handle it
}
catch(Exception5 ex)
{
// handle it
}
catch(Exception6 ex)
{
// handle it
}
catch(Exception7 ex)
{
// handle it
}
...
catch(Exception_n ex)
{
// handle it
}

Certainly, while not always appropriate, but sometimes if all you need to ignore
the exception and graciously continue the execution in the same manner no matter
what the exception is thrown, then catching the generic exception is the way to do.


Alex.

 

[Gene Wirchenko]

I keep on reading about how bad it is to catch Exception instead

of a more particular SomeKindOfException. But a method can
potentially throw a dozen of concrete exceptions. Are we really
supposed to chain a dozen catches like so?

[snip]

If the exceptions are to be handled individually, then yes. What
else would you do?

If you are just going to print out "Something bad happened!", you
do not need to. I suggest then that you watch out for enraged
maintenance programmers. At the very least, an error message should
state the error. "Particular bad thing 1 happened!"

Yes, I think that cascades of catch blocks are ugly and
obfuscatory, but that is the syntax.

Sincerely,

Gene Wirchenko

 

[Arne Vajhøj]

I keep on reading about how bad it is to catch Exception instead of a more particular SomeKindOfException. But a method can potentially throw a dozen of concrete exceptions. Are we really supposed to chain a dozen catches like so?

try
{
SomeMethodThatThrowsDozensOfExeptions();
}
catch(Exception1 ex)
{
// handle it
}
catch(Exception2 ex)
{
// handle it
}
catch(Exception3 ex)
{
// handle it
}
catch(Exception4 ex)
{
// handle it
}
catch(Exception5 ex)
{
// handle it
}
catch(Exception6 ex)
{
// handle it
}
catch(Exception7 ex)
{
// handle it
}
...
catch(Exception_n ex)
{
// handle it
}

A few comments:

1) If you need to handle N exceptions differently then
you need N x catch.

2) Those exceptions that you can handle identical and
have a common super class can be merged to a single
catch of the common super.

3) Using the class Exception will catch everything, but
you will typical only want to catch everything at the
outermost level.

4) The problem with so many possible exceptions is often
caused by layers being too tightly coupled. A layer should
not throw implementation specific exceptions. A layer
should catch implementation specific exceptions and
throw one or more exceptions defined as part of the
interface. Doing that will help keeping the number
of possible exceptions down.

Arne

 

[csharper]

<snip>

Realistically, if you are throwing that many exceptions, you are
probably not writing the method
in any kind of reasonable manner. Why would anything throw that kind
of exception number?

However, to go back to the issue, if you can handle the exception,
catch that type, do whatever
you need to do. If you can't, either re-throw it via catch or just
die, depending on what your needs
are.

Matt

For example, Directory.Delete(string path, bool recursive) can potentially throw 6 types of exceptions. See http://msdn.microsoft.com/en-us/library/fxeahc5f.aspx .

Suppose, in my application, I'd like to delete a folder and its content andthen recreate it, I feel that I should catch all 6 types of exceptions.

 

[csharper]

SomeKindOfException. But a method can potentially throw a dozen of concrete exceptions.

Are we really supposed to chain a dozen catches like so?

Certainly, while not always appropriate, but sometimes if all you need toignore
the exception and graciously continue the execution in the same manner nomatter
what the exception is thrown, then catching the generic exception is the way to do.


Alex.

You are right onto the point. Suppose I need to generate a report using thousands of Employee data. I don't want the application to crash simply because 1 or 2 Employee data causes my method (which may throw a dozen exceptions for example) to throw some uncaught exception. I want the report generation to complete. OK, got it, catching the base Exception is the way to go.

 

[csharper]

A few comments:

1) If you need to handle N exceptions differently then
you need N x catch.

2) Those exceptions that you can handle identical and
have a common super class can be merged to a single
catch of the common super.

3) Using the class Exception will catch everything, but
you will typical only want to catch everything at the
outermost level.

Thanks, but will it catch everything? I had thought that gurus say that it's bad to catch the general Exception because it won't give us the detailed,more specific problem than if we catch SomeMoreSpecificException. Is my understanding incorrect?

4) The problem with so many possible exceptions is often
caused by layers being too tightly coupled. A layer should
not throw implementation specific exceptions. A layer
should catch implementation specific exceptions and
throw one or more exceptions defined as part of the
interface. Doing that will help keeping the number
of possible exceptions down.

So, is it safe to say that in general it is good practice to design our methods to throw as fewer exceptions as possible?

 

[Matt]

For example, Directory.Delete(string path, bool recursive) can potentially throw 6 types of exceptions. Seehttp://msdn.microsoft.com/en-us/library/fxeahc5f.aspx.

Suppose, in my application, I'd like to delete a folder and its content and then recreate it, I feel that I should catch all 6 types of exceptions.

Realistically, you can do nothing about most of those errors.
Obviously, you can check for bad
arguments before calling the method in the first place, which
eliminates some of them. The rest,
however, are things that you can't do much to change.

You could simply catch Exception, show the user the underlying
problem, and move on. Catching
an exception to do anything other than log it or show an error is kind
of silly, since you aren't actually
fixing the problem.

But I do see your point.

Matt

 

[Jeff Johnson]

Thanks, but will it catch everything? I had thought that gurus say that
it's bad to
catch the general Exception because it won't give us the detailed, more
specific
problem than if we catch SomeMoreSpecificException. Is my understanding
incorrect?

Well, your question kind of contradicts itself. The point of letting
everything fall into the "catch-all" catch block is that you DON'T CARE
anout the "detailed, more specific problem." If you DO care then you SHOULD
be trapping the specific exception type. Do you understand?

 

[Arne Vajhøj]

For example, Directory.Delete(string path, bool recursive) can potentially throw 6 types of exceptions. See http://msdn.microsoft.com/en-us/library/fxeahc5f.aspx .

Suppose, in my application, I'd like to delete a folder and its content and then recreate it, I feel that I should catch all 6 types of exceptions.

Not necessarily.

Because the hierarchy is:

SystemException
IOException
PathTooLongException
DirectoryNotFoundException
UnauthorizedAccessException
ArgumentException
ArgumentNullException

You can chose between catching 1, 3 or 6 different exceptions
depending on your requirements.

Arne

 

[Arne Vajhøj]

Realistically, you can do nothing about most of those errors.
Obviously, you can check for bad
arguments before calling the method in the first place, which
eliminates some of them. The rest,
however, are things that you can't do much to change.

You could simply catch Exception, show the user the underlying
problem, and move on. Catching
an exception to do anything other than log it or show an error is kind
of silly, since you aren't actually
fixing the problem.

Unless we are talking outermost level, then I would go for
the lowest common super class (SystemException) and
Exception.

Arne

 

[Arne Vajhøj]

Thanks, but will it catch everything? I had thought that gurus say that it's bad to catch the general Exception because it won't give us the detailed, more specific problem than if we catch SomeMoreSpecificException. Is my understanding incorrect?

Catching Exception should catch all exception classes (I seem to recall
there being some exception introduced in 4.0, but let us forget about
that for now).

Even though you catch Exception you can still log the specific
exception class and the associated messages.

But you should only catch Exception at the outermost level to
avoid catching certain difficult to handle exceptions.

So, is it safe to say that in general it is good practice to design our methods to throw as fewer exceptions as possible?

It is good practice to not throw implementation specific exceptions
in a layers/components interface.

It is good practice to keep layers/components focused on a
specific role in the overall architecture.

Typical that will result in methods not throwing that many
exceptions.

Arne

 

[Matt]

Unless we are talking outermost level, then I would go for
the lowest common super class (SystemException) and
Exception.

True, a better answer.

Really, my point is simply to only handle the things you can actually
do something about. The rest of them generally fall under "no clue
what
to do here, punt".

Matt

 

[Arne Vajhøj]

Unless we are talking outermost level, then I would go for
the lowest common super class (SystemException) and
Exception.

I hope people were able to read the missing not ...



Arne