Structured Exception Handling and 'Resume Next'

  • Thread starter Thread starter Verde
  • Start date Start date
V

Verde

During exception processing, VB6 has the ability to resume execution at the
line of code that choked (Resume), or to resume execution at the line of
code immediately following the line that failed (Resume Next). Is there any
way to get similar behavior in .NET SEH? I'm specifically interested in
learning how to get execution to continue at the next line when one line of
code fails (the equivalent of Resume Next).

Thanks in advance!

-V
 
Hi Verde,

Verde said:
During exception processing, VB6 has the ability to resume execution at the
line of code that choked (Resume), or to resume execution at the line of
code immediately following the line that failed (Resume Next). Is there any
way to get similar behavior in .NET SEH? I'm specifically interested in
learning how to get execution to continue at the next line when one line of
code fails (the equivalent of Resume Next).
Click to expand...

VB.NET has Resume Next. C# does not. You should know that using Resume
Next will increase the size of a routine and make it slower. For every line
of code, extra instructions are generated to maintain a "line counter"
value. This value is used in the error handler to determine where to
"resume" executing after an exception.

Regards,
Dan
 
Okay, I'm using C#. Apparently if I want to continue execution after any
specific line of code, then I have to put that individual line of code in
its own try... catch block? Are there alternatives?

Thanks again

-V
 
Verde said:
Okay, I'm using C#. Apparently if I want to continue execution after
any specific line of code, then I have to put that individual line of
code in its own try... catch block? Are there alternatives?
Click to expand...

That is what your finally block is for. You try something, you catch or not
depending on requirements, and finally you execute some code regardless of
whether or not an exception was thrown.
--
Tom Porterfield
MS-MVP MCE
http://support.telop.org

Please post all follow-ups to the newsgroup only.
 
That is what your finally block is for. You try something, you catch or
not
depending on requirements, and finally you execute some code regardless of
whether or not an exception was thrown.
Click to expand...

Just for my understanding, is it true then that if I have multiple lines of
code - each of which might throw an error that I want to handle, and then
proceed to the next line of code, that I'd to put the first line of code in
a try... catch... block, and in the finally block put another try block -
this one for the next line of code, etc... such that there are multiple
try... catch... blocks, nested within the finally block of the "next outer"
try... catch... finally block? Something like this:

try {
line 1 here;
}
catch {
handle any error for line 1 here;
}
finally {
try {
line 2 here;
}
catch {
handle any error for line 2 here;
}
finally {
try {
line 3 here;
}
catch {
handle any error for line 3 here;
}
finally {
etc and so one and continue nesting here...
}
}
}
 
Verde,

I would not recommend you writing code like this, first of all there are
some
problems with memory leaks [1], but you should write it like this (note this
is
just an example and not a a guideline to which exceptions you always should
try to catch)

try
{
// A couple of lines of code, each which is
// able to throw an exception.
}
catch(SecurityException a)
{
// Catch any security exceptions
}
catch(ArgumentNullException b)
{
// Catch wrong arguments
}
catch(Exception c)
{
// When all else fails, catch the sucker
// anyway =)
}

[1] http://support.microsoft.com/default.aspx?scid=kb;en-us;810178

HTH,

//Andreas
 
I agree with your points and recommendations, and I would never want to
write a bunch of nested try... catch finally blocks. I was primarily
interested in discovering the alternatives in .NET/C# SEH to Resume and
Resume Next. Apparently there are none in C# and I can live with that. I'm
just a bit surprised that the show pretty much has to be over when you run
into an error. That is, one apparently cannot have logic that, when an
exception is encountered, can continues on it's happy way if the
error-handling logic determines that proceeding is okay. So, for example if
I have code that's doing a bunch of important tasks, and in the middle of
those tasks it goes to write some unimportant-but-interesting things to a
log file; if the log file cannot be written to (and an exception is thrown),
then I cannot, in C#, have logic that allows the important tasks to finish
even though an unimportant task of writing to the log file caused an
exception. Of course I could break up the logic into separate methods - but
short of doing that, there are apparently no good options for proceeding
after an exception is thrown. Okay.

-v


Andreas Håkansson said:
Verde,

I would not recommend you writing code like this, first of all there are
some
problems with memory leaks [1], but you should write it like this (note this
is
just an example and not a a guideline to which exceptions you always should
try to catch)

try
{
// A couple of lines of code, each which is
// able to throw an exception.
}
catch(SecurityException a)
{
// Catch any security exceptions
}
catch(ArgumentNullException b)
{
// Catch wrong arguments
}
catch(Exception c)
{
// When all else fails, catch the sucker
// anyway =)
}

[1] http://support.microsoft.com/default.aspx?scid=kb;en-us;810178

HTH,

//Andreas

Verde said:
or
not
Click to expand...
regardless
of

Just for my understanding, is it true then that if I have multiple lines of
code - each of which might throw an error that I want to handle, and then
proceed to the next line of code, that I'd to put the first line of code in
a try... catch... block, and in the finally block put another try block -
this one for the next line of code, etc... such that there are multiple
try... catch... blocks, nested within the finally block of the "next outer"
try... catch... finally block? Something like this:

try {
line 1 here;
}
catch {
handle any error for line 1 here;
}
finally {
try {
line 2 here;
}
catch {
handle any error for line 2 here;
}
finally {
try {
line 3 here;
}
catch {
handle any error for line 3 here;
}
finally {
etc and so one and continue nesting here...
}
}
}
Click to expand...
Click to expand...
 
Handling this via code structure is probably better then a bunch of nested
try blocks. If you have something like a logger, make that another method
(as you said.) Wrap that whole method in a try/catch block. If it fails,
return a bool of false or true if good instead of another exception. Use
exceptions for things your program can't recover from (i.e. can't connect to
server so nothing you can do, etc.), use program logic (i.e. if testing) for
things you can recover from or skip.

--
William Stacey, MVP

Verde said:
I agree with your points and recommendations, and I would never want to
write a bunch of nested try... catch finally blocks. I was primarily
interested in discovering the alternatives in .NET/C# SEH to Resume and
Resume Next. Apparently there are none in C# and I can live with that. I'm
just a bit surprised that the show pretty much has to be over when you run
into an error. That is, one apparently cannot have logic that, when an
exception is encountered, can continues on it's happy way if the
error-handling logic determines that proceeding is okay. So, for example if
I have code that's doing a bunch of important tasks, and in the middle of
those tasks it goes to write some unimportant-but-interesting things to a
log file; if the log file cannot be written to (and an exception is thrown),
then I cannot, in C#, have logic that allows the important tasks to finish
even though an unimportant task of writing to the log file caused an
exception. Of course I could break up the logic into separate methods - but
short of doing that, there are apparently no good options for proceeding
after an exception is thrown. Okay.

-v


Andreas Håkansson said:
Verde,

I would not recommend you writing code like this, first of all there are
some
problems with memory leaks [1], but you should write it like this (note this
is
just an example and not a a guideline to which exceptions you always should
try to catch)

try
{
// A couple of lines of code, each which is
// able to throw an exception.
}
catch(SecurityException a)
{
// Catch any security exceptions
}
catch(ArgumentNullException b)
{
// Catch wrong arguments
}
catch(Exception c)
{
// When all else fails, catch the sucker
// anyway =)
}

[1] http://support.microsoft.com/default.aspx?scid=kb;en-us;810178

HTH,

//Andreas

Verde said:
That is what your finally block is for. You try something, you
Click to expand...
Click to expand...
catch
or regardless lines
of code
in
Click to expand...
Click to expand...
 
Dim sqlConn as new SqlConnection("server=localhost;etc...")
Dim sqlCmd as new SqlCommand("select * from table,sqlConn)
Dim sqlR as sqlDataReader
sqlConn.Open()
Try
sqlR=sqlCmd.ExecuteReader()
Catch e as Exception

Finally
' This block, since it would be executed regardless of whether the try
was successful or not, would, perhaps, be the ideal place to go ahead
and do some common operation. You will need to close the connection
regardless.
sqlConn.Close()
End Try

with regards,


J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
 
Back
Top