VB Resume statement equivalent in try-catch ....

[Darta]

OK- I volunteer to be shot if this question is stupid... BUT, is there
a way to, when you catch an exception in the catch{} handler, resume
to the same line of code that generated an error while you are
debugging within IDE...? Here is an example from VB:

Private SomeFunction ()
On Error GoTo ErrHandler:

MyMethod this, that

Exit Function
ErrHandler:
Err.Raise smth, smth, smth
Exit Function ' this is for safe-keeping, although not necessary
since
' Err.Raise exits the function anyways
Resume
End Function

In VB world, I would set a breakpoint on Err.Raise line, the execution
will stop when error happens on that line, then I would -manually-
drag a cursor to Resume, and then Step Into would bring me to the
exact line that cause the error in the function. This was very handy
and effective as I could immediatelly tell which call caused the error
and with next Step Into, what was the error while debugging. I can't
find a similar way in catch{} statement. You can view the message,
get Source and StackTrace, and all the other stuff from the various
Exception objects, but you have to read all those properties to see
where exactly the error occurred - which is so much slower than the
way I described. Or there might be a way to do this in C#, which I am
not aware of... (also, as you noticed, my VB approach is only for
debugging purposes, as Resume will never executed when running the
code real time as Err.Raise exits the function anyways...)

Any help is greatly appreciated.
Tigger

[William Ryan]

Tigger:

When I first came to my shop, they didn't use Structured Exception handlers
at all b/c they used this same method and coudln't get line numbers of the
exception. They were using ex.Message and this didn't give them what they
needed.
Use a Try Catch block and then in your exception handler, Exception.ToString
will give you the exact line number and description of the error, coupled
with the stack trace.

This should get you what you want.

HTH,

Bill
"Darta" <tv****@hotmail.com> wrote in message
news:db**************************@posting.google.c om...

OK- I volunteer to be shot if this question is stupid... BUT, is there
a way to, when you catch an exception in the catch{} handler, resume
to the same line of code that generated an error while you are
debugging within IDE...? Here is an example from VB:

Private SomeFunction ()
On Error GoTo ErrHandler:

MyMethod this, that

Exit Function
ErrHandler:
Err.Raise smth, smth, smth
Exit Function ' this is for safe-keeping, although not necessary
since
' Err.Raise exits the function anyways
Resume
End Function

In VB world, I would set a breakpoint on Err.Raise line, the execution
will stop when error happens on that line, then I would -manually-
drag a cursor to Resume, and then Step Into would bring me to the
exact line that cause the error in the function. This was very handy
and effective as I could immediatelly tell which call caused the error
and with next Step Into, what was the error while debugging. I can't
find a similar way in catch{} statement. You can view the message,
get Source and StackTrace, and all the other stuff from the various
Exception objects, but you have to read all those properties to see
where exactly the error occurred - which is so much slower than the
way I described. Or there might be a way to do this in C#, which I am
not aware of... (also, as you noticed, my VB approach is only for
debugging purposes, as Resume will never executed when running the
code real time as Err.Raise exits the function anyways...)

Any help is greatly appreciated.
Tigger

[Daniel Pratt]

Hi Darta,

"Darta" <tv****@hotmail.com> wrote in message
news:db**************************@posting.google.c om...

OK- I volunteer to be shot if this question is stupid... BUT, is there
a way to, when you catch an exception in the catch{} handler, resume
to the same line of code that generated an error while you are
debugging within IDE...? Here is an example from VB:

<snip>

There is no direct equivalent to Resume in C#.

You might find it interesting to see the difference in the generated
machine instructions when you use Resume v.s. when you don't. Obviously
there isn't a one-to-one relationship between code lines and generated
machine code instructions. So how does your VB program "know" which line it
should resume to? The answer is that an invisible line counter is maintained
in any routine that uses Resume or Resume Next. For every line of code an
extra instruction is generated to increment the line counter.

In other words, simply by including the Resume or Resume Next statement
in a routine will slow the routine down, even if the Resume or Resume Next
statement is never executed. I doubt the difference is significant in most
cases, but it's interesting anyway.

Regards,
Dan