catching more than one type of Exception

[Tom P.]

I have a situation that requires me to catch two different types of
exceptions but do the same processing. Is there a way to do this? In
VB you can stack the Catch statements but what do I do in C#?

For example:

try
{
....
}
catch(IndexOutOfRangeException)
catch(FormatException)
{
....
}
Or something like that.

TIA,
Tom P.

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Tom P. wrote:

I have a situation that requires me to catch two different types of
exceptions but do the same processing. Is there a way to do this? In
VB you can stack the Catch statements but what do I do in C#?

You can't.

I would argue that this is good, because later the two catch'es
may need to execute different code.

Arne

[Peter Duniho]

On Fri, 08 Aug 2008 13:53:58 -0700, Tom P. <pa***********@gmail.comwrote:

I have a situation that requires me to catch two different types of
exceptions but do the same processing. Is there a way to do this? In
VB you can stack the Catch statements but what do I do in C#?

For example:

try
{
...
}
catch(IndexOutOfRangeException)
catch(FormatException)
{
...
}
Or something like that.

You can do:

try
{
// ...
}
catch (Exception exc)
{
if (exc is IndexOutOfRangeException ||
exc is FormatException)
{
// do something
}
else
{
throw;
}
}

or:

void MethodA()
{
try
{
// ...
}
catch (IndexOutOfRangeException)
{
MethodAExceptionHandler();
}
catch (FormatException)
{
MethodAExceptionHandler();
}
}

void MethodAExceptionHandler()
{
// do something
}

But, as Arne says, it may be better to do neither because eventually it
may make sense for the handling to depend on the type of exception.

In fact, the fact that you are trying to handle two different exceptions
in the same way strongly suggests that you are already heading down the
wrong road. If you are handling two different exceptions identically,
then at the very least it's debateable whether you really ought to be
handling each one individually, as opposed to just handling a shared base
class between the two. And it's possible it's a mistake to be handling
the exceptions at all. After all, if you can treat the two disaparate
exceptions identically, just how much real exception recovery could you be
doing at that point?

It's hard to say without knowing more about the rest of the code. But you
definitely should be proceeding carefully.

Pete

[Peter Duniho]

On Sat, 09 Aug 2008 12:48:56 -0700, Tom P. <pa***********@gmail.comwrote:

[...] So far I choose to handle both of these
instances the same way, by simply ignoring the string in the renaming
process. I'm not sure yet that I want to ignore EVERY exception, but
so far these two do, in fact, have the same resolution.

But that resolution has little to do with their actual types. You could
just as easily catch the type "Exception". If later you have some other
exception that you want to provide more specific handling for, then you
can include a catch clause specific to that exception (putting it before
the one that catches "Exception", of course).

It might be that in the future, you want to provide the user with better
feedback about why their input is wrong. The user certainly would have a
much better idea of how to fix their input that's not working if they know
whether it's a problem with the format of that input (i.e. entering a
letter when a number was expected) or the meaning of that input (i.e.
entering a number that is itself invalid). And of course, it's also much
easier to fix a problem if the user is actually informed that there's a
problem, but that's a separate issue. :)

But in the meantime, if you're just ignoring the errors, you don't need to
catch a specific exception. Add a specific exception clause if and when
you have something you want to do that actually requires knowing what the
type of the exception is.

Pete

[=?UTF-8?B?QXJuZSBWYWpow7hq?=]

Peter Duniho wrote:

On Sat, 09 Aug 2008 12:48:56 -0700, Tom P. <pa***********@gmail.comwrote:

>[...] So far I choose to handle both of these
instances the same way, by simply ignoring the string in the renaming
process. I'm not sure yet that I want to ignore EVERY exception, but
so far these two do, in fact, have the same resolution.

But that resolution has little to do with their actual types. You could
just as easily catch the type "Exception".

Usually there are some exceptions that you do not want to catch except
at the outermost level. Example: OutOfMemoryException.

Arne

[Peter Duniho]

On Sun, 10 Aug 2008 16:45:51 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:

Usually there are some exceptions that you do not want to catch except
at the outermost level. Example: OutOfMemoryException.

Well, that depends on what you intend to do with the exception. However,
the OP stated he would just ignore the exception. So what does he care
whether it's OOM or a user input problem? If it's an OOM issue that
matters, he'll get another exception later, and if it's not, then letting
it filter up higher isn't necessary.

Of course, the OP's already stated that he's not actually going to do
anything to handle the exception, but rather will just ignore them, so I
don't see anything wrong with just having two different empty catch
clauses. I'm really just speaking hypothetically at this point with
respect to using a base class in the catch clause.

Pete