intercepting a handled exception in the debugger

[colin]

Is it possible to do this ? i cant see any likly options.
I have an exception handler but I want to examine the exception before
it gets to the handler, Is there a way to do this ?

At the moment i have to comment out the exception handler
to examine whats going on at the time of the exception in more detail.

but if its not the first exception that ocurs that I want to debug
then im stuck, is there a way to deal with this ?

I have different types of exception handler wich I comment out wich helps.

Colin =^.^=

[=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=]

Your post is somewhat unclear because it doesn't specify how the exception
handler works. If you have a try / catch block, you should be able to set a
breakpoint on the line where your "exception handler" (Whatever it is) gets
called, and examine the exception via Intellisense and visualizers.

--Peter
"Inside every large program, there is a small program trying to get out."
http://www.eggheadcafe.com
http://petesbloggerama.blogspot.com
http://www.blogmetafinder.com

"colin" wrote:

Is it possible to do this ? i cant see any likly options.
I have an exception handler but I want to examine the exception before
it gets to the handler, Is there a way to do this ?

At the moment i have to comment out the exception handler
to examine whats going on at the time of the exception in more detail.

but if its not the first exception that ocurs that I want to debug
then im stuck, is there a way to deal with this ?

I have different types of exception handler wich I comment out wich helps.

Colin =^.^=

[colin]

"Peter Bromberg [C# MVP]" <pb*******@yahoo.NoSpamMaam.comwrote in message
news:D8**********************************@microsof t.com...

Your post is somewhat unclear because it doesn't specify how the exception
handler works. If you have a try / catch block, you should be able to set
a
breakpoint on the line where your "exception handler" (Whatever it is)
gets
called, and examine the exception via Intellisense and visualizers.

sorry yes its just a try catch block, i didnt know of any other type.
but if I set a breakpoint in the catch
block then I havnt got access to any variables that were on the stack
at the time the exception happened.

for example say an index is out of range I want to know what the index was,
and what other variables were that led to that index value.
Colin =^.^=

[=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=]

Well, this is kind of a Catch-22. If an index was out of range, that would be
why you are in the catch block, and the exception message and stacktrace
would reflect that, no?
--
--Peter
"Inside every large program, there is a small program trying to get out."
http://www.eggheadcafe.com
http://petesbloggerama.blogspot.com
http://www.blogmetafinder.com

"colin" wrote:

>
"Peter Bromberg [C# MVP]" <pb*******@yahoo.NoSpamMaam.comwrote in message
news:D8**********************************@microsof t.com...

Your post is somewhat unclear because it doesn't specify how the exception
handler works. If you have a try / catch block, you should be able to set
a
breakpoint on the line where your "exception handler" (Whatever it is)
gets
called, and examine the exception via Intellisense and visualizers.

sorry yes its just a try catch block, i didnt know of any other type.
but if I set a breakpoint in the catch
block then I havnt got access to any variables that were on the stack
at the time the exception happened.

for example say an index is out of range I want to know what the index was,
and what other variables were that led to that index value.
Colin =^.^=

[colin]

"Peter Bromberg [C# MVP]" <pb*******@yahoo.NoSpamMaam.comwrote in message
news:BD**********************************@microsof t.com...

Well, this is kind of a Catch-22. If an index was out of range, that would
be
why you are in the catch block, and the exception message and stacktrace
would reflect that, no?

I dont know about catch22, I just want the debuger to intercept the
exception before
it gets to my catch block (so i can see all the variables as if there was no
catch block)
but then to allow me to let the catch block handle the exception and carry
on.

im sure ive seen similar option in other ide.

the exception message displays quite a bit of usefull information,
but just knowing an index was out of range is not sufficient on its own,
the code im debugging is a serialisation routine,
and the index is extracted from the file,
if it goes negative for example it usually means it has got out of step
reading the previous fields.

when the stack unwinds and gets back to the catch block the information
about the previous fields is lost.

I have put traps and checks in various places, the best way so far is to
have a function wich wraps
the try-catch around the serilisation routine,
if it gets to the catch then to optionaly call the function again with the
same parameters with no try-catch.

Colin =^.^=

In VS 2005,

Debug --Exceptions
(Or Ctrl + d, e)

You can choose which exceptions (individual or by group) you want the IDE to
break on, before passing them to a catch block.

Hope that helps

--
Ged Moretta
www.appsense.com

-----------------------------------------------------------------------
This signature isn't automatic. I have to type it manually every time.
"colin" <co*********@ntworld.NOSPAM.comwrote in message
news:EG*******************@newsfe1-gui.ntli.net...

"Peter Bromberg [C# MVP]" <pb*******@yahoo.NoSpamMaam.comwrote in
message news:BD**********************************@microsof t.com...

>Well, this is kind of a Catch-22. If an index was out of range, that
would be
why you are in the catch block, and the exception message and stacktrace
would reflect that, no?

I dont know about catch22, I just want the debuger to intercept the
exception before
it gets to my catch block (so i can see all the variables as if there was
no catch block)
but then to allow me to let the catch block handle the exception and carry
on.

im sure ive seen similar option in other ide.

the exception message displays quite a bit of usefull information,
but just knowing an index was out of range is not sufficient on its own,
the code im debugging is a serialisation routine,
and the index is extracted from the file,
if it goes negative for example it usually means it has got out of step
reading the previous fields.

when the stack unwinds and gets back to the catch block the information
about the previous fields is lost.

I have put traps and checks in various places, the best way so far is to
have a function wich wraps
the try-catch around the serilisation routine,
if it gets to the catch then to optionaly call the function again with the
same parameters with no try-catch.

Colin =^.^=

[colin]

<Gedwrote in message news:eV**************@TK2MSFTNGP04.phx.gbl...

In VS 2005,

Debug --Exceptions
(Or Ctrl + d, e)

You can choose which exceptions (individual or by group) you want the IDE
to break on, before passing them to a catch block.

Hope that helps

cool yes thanks that does exactly what I want :D

I was looking in the wrong place, I hadnt even come accros that window
before.

I checked on break on throw and it stoped at the problem then allowed me to
continue
and handle it in the catch block.

Colin =^.^=