Throwing Exceptions

[Jay Dee]

I have a query about throwing exceptions.

To throw an exception I type something like:

try
{
// do somthing
}
catch (ArgumentOutOfRangeException)
{
throw new Exception("My Exception");
}

And when the try section fales my excepton is thrown and if not court
elswair will display when debuging and hi-light the line:

throw new Exception("My Exception");

but when using other classes like in the microsoft framework library
the line that is hi-lighted is the line that called the class
containing that exception.

What I am trying to say is that when my exception is thrown I no that
it has bean thrown but I don't know what corsed it to throw, so it is
fearly useles being there.

Any sugestions.

Thanks, Jay Dee.

 

[Alvin Bruney [MVP]]

couple things i am not sure why you are catching a specific exception and
rethrowing it as a general exception - reason for this? To your question,
what you will need to do is view the exception.Message property and it
should contain the string "my exception" which is normally the reason that
you set when you throw an exception. makes sense?

 

[Peter Duniho]

[...]
And when the try section fales my excepton is thrown and if not court
elswair will display when debuging and hi-light the line:

throw new Exception("My Exception");

but when using other classes like in the microsoft framework library
the line that is hi-lighted is the line that called the class
containing that exception.

The difference there is basically because you don't have the source code
to the .NET code. So the debugger shows you the source code that is
closest to the thrown exception. If your own code throws an exception,
then that code is the code that threw the exception. But if some other
code throws an exception, then the closest code will still be in your
own code where it called the code for which the source code is absent.

What I am trying to say is that when my exception is thrown I no that
it has bean thrown but I don't know what corsed it to throw, so it is
fearly useles being there.

That's right. As Alvin says, it's not at all clear why you write the
code like that. You had a perfectly good exception. If you're not
going to handle it (that is, recover from it) then why hide it with a
whole new exception? Especially one that is a generic one, rather than
the original one.

At the very least, you could just write "throw;" instead of "throw new
Exception("My Exception");" At least that would cause the exception
thrown to be the same as the one that was caught. If I recall, the
stack trace will be wrong, but if you fix the "catch" statement so that
it declares a local ArgumentOutOfRangeException variable, then at least
you can look at that variable in the debugger and see what the stack
trace is (but only if you put a breakpoint before your own "throw"
statement, of course).

My experience has been that it's almost always a mistake to rethrow an
exception or throw a new exception from a "catch" clause. Sometimes
it's what you want to do, but usually it's better to either just handle
the error locally in the "catch" clause or put whatever cleanup code you
thought should go in the "catch" clause into the "finally" clause
instead, and just not catch any exception.

Pete

 

[piccante]

What I am trying to say is that when my exception is thrown I no that

it has bean thrown but I don't know what corsed it to throw, so it is
fearly useles being there.

If you want to know what caused the exception, you should check
the call stack. There you can see who called the method which caused
the exception.

piccante

 

[Matt Brunell]

In visual studio, You can break automatically when an exception is thrown,
or is unhandled. The default behavior for the debugger is to break when an
exception is unhandled.

Thus, when you are trying to throw the 'My Exception' below, the debugger
will break the running process. The debugger did not break on the line
inside the try block that threw the 'ArgumentOutOfRangeException' because
the exception was handled.

You can change this by going to Debug | Exceptions. Expand 'Common Language
Runtime Exceptions' and select the exceptions which you want the debugger to
break on as soon as they are thrown.