General questions on exceptions

[Paul]

In general how do you indentify a specific error? If 2 different error
conditions throw the same type of exception how do you know which error
occured? There are no error numbers, so are you forced to compare
Message strings? But these strings are locale dependent, so that
wouldn't work.

Also, is there a complete table or listing of possible framework errors?
I've never seen one.

[Jon Skeet [C# MVP]]

Paul <---@---.---> wrote:

In general how do you indentify a specific error? If 2 different error
conditions throw the same type of exception how do you know which error
occured? There are no error numbers, so are you forced to compare
Message strings? But these strings are locale dependent, so that
wouldn't work.

Also, is there a complete table or listing of possible framework errors?
I've never seen one.

In general, you shouldn't need to rely on anything more specific than
the type of exception. Unfortunately, that's not always the case -
sometimes the same exception is given for different reasons, one of
which you can handle and one of which you can't. There's no good,
reliable way of determining the difference.

The only complete listing of possible framework exceptions is the one
you get by looking at the MSDN docs for Exception, and look for all the
derived classes.

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

[Bruce Wood]

There is one situation that you can do something about. If you are
having to distinguish between two exceptions coming out of one of your
own routines, but which originate in two different calls down to the
..NET Framework, you can catch each of them in your code and "wrap" them
in different exceptions so that you can distinguish them.

For example, if you have a method:

public void DoSomethingOrOther(object param1, object param2)
{
// Call a Framework method with param1
FrameworkMethod1(param1);

// Call a Framework method with param2
FrameworkMethod2(param2);
}

Now, either of these calls could throw an ArgumentNullException, if one
of param1 or param2 was null. Which framework method throws the
exception depends upon which argument is null. From the outside of
DoSomethingOrOther, the two exceptions are indistinguishable. However,
you could change that by doing this:

public void DoSomethingOrOther(object param1, object param2)
{
try
{
// Call a Framework method with param1
FrameworkMethod1(param1);
}
catch (ArgumentNullException ane)
{
throw new MyApplicationException("Something-or-other can't be
null.", ane);
}

// Call a Framework method with param2
FrameworkMethod2(param2);
}

Now you can distinguish the (recoverable) condition of the first
parameter being null from the (unrecoverable) condition of the second
parameter being null.

Of course, this works only in this circumstance. It doesn't work if a
single Framework method happens to throw the same exception under two
different conditions, and you want to recover from one and not the
other. In that case, you're out of luck. :(

[Paul]

> Of course, this works only in this circumstance. It doesn't work if a

single Framework method happens to throw the same exception under two
different conditions, and you want to recover from one and not the
other. In that case, you're out of luck. :(

This is my problem -- the framework provides no way to narrow down the
error in some cases. But it's true that usually the exception type is
all you need.

I found today that in the case of SocketException the error has detailed
socket error codes returned from the underlying API. I just wish all the
exceptions had a unique code number you could look up. I feel very old
school.