Resume Next Equivalent with Try... Catch?

[JDYoder]

I've been using Try... Catch, but at times I want to use Resume or Resume Next. I know I can use On Error, but I've been trying to avoid that. So is there a Resume / Resume Next equivalent with Try... Catch?

[Wile]

Not really. The only option you have is to split one singel try..catch block into several blocks. If the first error is caught, the code will continue with the next try.. catch block. Something like:

 

public void MyMethod()

{

try

{

...

..

}

catch(Exception ex)

{

}

//now do some more stuff

try

{

.....

....

}

catch (Exception ex)

{

}

}

[Afraits]

Wile's method gives you the resume next equivalent, to do a resume the best I can come up with is this

bool retryvar=false;
do
{  
 try
 {
   //do stuff

   //end loop
   retryvar=false;
 }
 catch(SpecificException Ex)
 {
   //known correctable error so correct then
   retryvar=true;//set var to retry
 }
 catch(Exception Ex)
 {
   //errorcorrectable fake var to show whether you could retry or not
   if (errorcorrectable) retryvar=true;//set var to retry
   else retryvar=false;
 }
}while(retryvar);

 

You could use int var instead of boolean to show return codes and control program flow for subsequent statements. And yes this is very longwinded syntax.

[mskeel]

And yes this is very longwinded syntax.

It is also extremely bad practice. Exception handling should only be used to catch errors and problems that are truely exceptional -- things that you really didn't see coming. If you catch something that is a "known correctable error" then why allow the exception to throw in the first place? Just do a check for the condition before you execute the code that may throw the error. An easy example of this is the null-reference error. Do you check to see if an object is null before you use it or do you use it and catch the exception? You check to see if the object is null before you use it -- it should be the first thing you do.

 

If the pragmatic argument isn't good enough as to why you shouldn't use try..catch to control the flow of you program then the speed arguement should be. A large preformance hit is taken each time an exception is thrown. Exception handling is very expensive and you will have a noticable dip in preromance if you use the code above.

A good article on exceptions

See the paragraph "Throw fewer exceptions"

 

If there were native support for a resume..next syntax, perhaps it would be a good thing, but you can code the same logic just by looking at it from a different perspective and still accomplishing what you want without creating bad code in the process. It is just going to take a new perspective on the problem -- perhaps even one without resume..next.

[IngisKahn]

mskeel hits the nail on the head.

[Robby]

Nicely said mskeel.

 

Afraits, that peice of code looks like a recipe for disaster.

[iebidan]

You can use multiple catchs depending on the errors you expect and a generic catch.

What I do is in the generic catch send a fatal error or try to do some code, if everything fails that's when I send the fatal error message or capture it with the AppDomain Exception Handler I use in my apps.

[michael_hk]

Afraits' date=' that peice of code looks like a recipe for disaster.[/quote']

LOL :D

 

Using try-catch that way is just finding trouble yourself.

[Afraits]

Good point, well made. I stand chastised :D .

So maybe next time I'll ask why someone wants to do something rather than trying to answer the question and save myself being called a fool 4 times :P

 

Perhaps JDYOder could you tell us why you wanted a resume & resume next syntax so we could try to find you a way to avoid it in the first place?

 

By the way - once is usually enough for me, especially when its a comprehensive an explaination as that provided. :)

[JDYoder]

Thanks for the input. In that case, I'll go with On Error in certain situations in VB.NET since at times, I'd really like to use a Resume, which I use for debugging purposes. For example, in VB6, when I'd have some longer routines and I wanted to easily find the problem line without tracing from the top and going line-by-line, I'd use the following structure to speed up debugging...

 

Private SubName()

On Error Goto ErrHandler

...

...

...

ErrHandler:

Msgbox Err.Description

Exit Sub

Resume

End Sub

 

The execution will never reach the "Resume" line on its own. However, when it pops up the error message, I'd hit Ctrl-Break, which placed me on the "Exit Sub" line. Rather than execute that line, I'd dragged the yellow "Next Statement" arrow down to "Resume", then only execute that line, which would pop me up to the line it had bombed on.

 

I had hoped VB.NET would have something along these lines with Try... Catch so I wouldn't have to remove any "On Error" code that I'd be inserting just for this debugging method. That way, I could leave the code when I wanted to make an exe, like I would in VB6 in the above example. (Because like I said, the "Resume" never gets hit unless I manually do it to myself.)

 

There were also places where "Resume Next" was handy in routines you don't care about or they had some rare exception that wasn't worth coding for, so it was far more convenient to just let the code continue. Of course, that was typically the lazy method, which I understand and accept, but "Resume" used in the manner above can make debugging fast and easy.

[Wile]

If you only want to 'break' when an exception is thrown, visual studio can make your live easier. Under Debug->Exceptions, you can turn on/off breaking for all kinds of errors that are thrown (managed and unmanaged), specifying if you only want to break into debugging if the error is unhandled or in all cases the error is thrown.

[JDYoder]

Thanks. I'll play with that. :)

[PlausiblyDamp]

You may also want to investigate things like Debug.Assert and conditional compilation, there are definately better ways to handle debugging than relying on the resume statement.

[michael_hk]

So maybe next time I'll ask why someone wants to do something rather than trying to answer the question and save myself being called a fool 4 times :P

Afraits, your sample code is appreciated. It shows what developers should avoid in their code.

[bri189a]

I've said it before and I'll say it again, the first thing anyone should do when creating a VB.NET project is to remove the reference and namespace to the legacy VB6 library...

[Robby]

Afraits, I'm sure no one wanted to gang up on you nor to chastise you but merely to point out what not to do. Sometimes in answering these posts we don't always see the bigger picture (ie. why does the person even want to do this).

 

I've certainly been there with my foolish answers. :)

[Afraits]

I'd hoped the smilies had given the impression that I didn't really mind and that the comments were taken on board with good humour, and also that I knew no-one wanted to gang up me (though it did feel that way on first reading that morning :), though probably more due to atmosphere at work than that here! ). Just shows how easy it is to not make yourself clear...

 

Thanks for the reassurance though.

[JDYoder]

Thanks for the extra input, everyone. Very "above and beyond" what I needed. :)