How to try something repeatedly using try-catch?

  • Thread starter Thread starter Ed Staffin
  • Start date Start date
E

Ed Staffin

Hi,
In vb6, if I had an error handler I could catch an error,
make a correction and then try it again using resume. I
want to do the same thing in vb.net.

I am trying to deal with some concurrency issues. I want
to be able to catch a error, wait a few milliseconds and
then try it again. Any help on this would be great.
Thanks ... Ed
 
Perhaps with some embellishment, something like this may work:

Dim blnSuccess As Boolean

Do Until blnSuccess
Try
... 'Whatever needs to be done
blnSuccess = True
Catch e as exception
.... If it is the error you think you can retry then wait
End Try
Loop
 
Ed,
In addition to the Loop that Al showed, you can use Goto within a Catch
block to go to a label in the Try Block.

In this instance I consider Goto more of a Resume Try than an actual Goto.
;-)

Try
TryAgain:
... 'Whatever needs to be done
Catch e as exception
.... If it is the error you think you can retry then wait
Goto TryAgain
End Try

Normally I put an If around the "Resume Try" (goto) so as to avoid an
endless loop.

Something like:
Try
TryAgain:
AttemptToReadFile()
' Throw New System.IO.FileNotFoundException
Catch ex As System.IO.FileNotFoundException
If MessageBox.Show("What would you like to do?", "File not
found", MessageBoxButtons.RetryCancel, MessageBoxIcon.Question,
MessageBoxDefaultButton.Button2) = DialogResult.Retry Then
GoTo TryAgain
Else
Throw ' let error propagate up
End If
End Try

Hope this helps
Jay
 
Jay,

Somehow, the use of the "GoTo" statement just doesn't ever seem to come to mind as a solution unless I am *really* stuck and can
find no other way out. For others, it seems to be the first and only choice.

To each his own.

--
Al Reid

"It ain't what you don't know that gets you into trouble. It's what you know
for sure that just ain't so." --- Mark Twain
 
Something like this might work ok......

Dim bDone as boolean = false

Do
Try
.......
.......
.......

bDone = true

catch Ex as Exception

End Try

loop while not bDone
 
This code will give you a specified number of attempts to handle an exception..

Dim retries As Long = 3 'number of attempts before rethrowing to an outer level
Tr
retry:
retries -=
'normal code to execut
Catch ex As Exceptio
If (retries >= 0)
'Rectify problem..
GoTo retr
Else 'rethrow the exact same exception..
Throw e
End I
End Try
 
Ed,
In addition to the Loop that Al showed, you can use Goto within a Catch
block to go to a label in the Try Block.

Jay, is there any reason to put the label *inside* the Try instead of
outside it? Does it make any difference?

Try
TryAgain:
'Whatever
Catch
If SomeCondition Then
Goto TryAgain
EndIf
End Try


As opposed to this:

TryAgain:
Try
'Whatever
Catch
If SomeCondition Then
Goto TryAgain
EndIf
End Try
In this instance I consider Goto more of a Resume Try than an actual Goto.
;-)

I think adding a ReTry keyword would be nice, but like you said you'd have
to watch out for an endless loop. Perhaps the ReTry could have optional
parameters to prevent that:

ReTry [[MaxRetries][,RetryDelayMs]]

Just a thought
 
Al,
Unfortunately too many people feel that bad use of a Goto makes the Goto
bad.

I feel "correctness" is more important then any preconceived notions I may
have had about bad uses of Goto in the past.

Of course "correctness" is subjective.

Hope this helps
Jay

Al Reid said:
Jay,

Somehow, the use of the "GoTo" statement just doesn't ever seem to come to
mind as a solution unless I am *really* stuck and can
 
Chris,
Jay, is there any reason to put the label *inside* the Try instead of
outside it? Does it make any difference?
Yes there is a reason, it won't compile if its outside ;-)

I actually got this tip from Paul Vick's book "The Visual Basic .NET
Programming Language" from Addison Wesley. And yes he cautions, and I concur
that you should only use a Goto if its absolutely necessary.

Basically:
- A Goto can only branch from a Catch statement into the Try block of the
same statement
- A Goto can never branch out of a Finally statement
- A Goto can never branch into a Catch or Finally statement

He also lists that a Goto can cannot branch into With, For, For Each, or
SyncLock statements.
I think adding a ReTry keyword would be nice, but like you said you'd have
to watch out for an endless loop. Perhaps the ReTry could have optional
parameters to prevent that:

ReTry [[MaxRetries][,RetryDelayMs]]
I would include an optional label also, as you can have different Labels in
the Try block with different Goto's. I'm not sure how often I would have
more then a single Goto, as its not as obvious as a single goto what is
going on.

Try
TryAgain1:
Something()
TryAgain2:
SomethingElse()
Catch
If whatever Then
Goto TryAgain1
Else
Goto TryAgain2
End If
End Try


Hope this helps
Jay

Chris Dunaway said:
Ed,
In addition to the Loop that Al showed, you can use Goto within a Catch
block to go to a label in the Try Block.

Jay, is there any reason to put the label *inside* the Try instead of
outside it? Does it make any difference?

Try
TryAgain:
'Whatever
Catch
If SomeCondition Then
Goto TryAgain
EndIf
End Try


As opposed to this:

TryAgain:
Try
'Whatever
Catch
If SomeCondition Then
Goto TryAgain
EndIf
End Try
In this instance I consider Goto more of a Resume Try than an actual Goto.
;-)

I think adding a ReTry keyword would be nice, but like you said you'd have
to watch out for an endless loop. Perhaps the ReTry could have optional
parameters to prevent that:

ReTry [[MaxRetries][,RetryDelayMs]]

Just a thought


--
Chris

To send me an E-mail, remove the "[", "]", underscores ,lunchmeat, and
replace certain words in my E-Mail address.
 
D'oh!

I should add, because of these three rules:
- A Goto can only branch from a Catch statement into the Try block of the
same statement
- A Goto can never branch out of a Finally statement
- A Goto can never branch into a Catch or Finally statement

I consider this more of a "Resume Try" and its use is more acceptable then
most other uses of Goto.

Jay

Jay B. Harlow said:
Chris,
Jay, is there any reason to put the label *inside* the Try instead of
outside it? Does it make any difference?
Yes there is a reason, it won't compile if its outside ;-)

I actually got this tip from Paul Vick's book "The Visual Basic .NET
Programming Language" from Addison Wesley. And yes he cautions, and I concur
that you should only use a Goto if its absolutely necessary.

Basically:
- A Goto can only branch from a Catch statement into the Try block of the
same statement
- A Goto can never branch out of a Finally statement
- A Goto can never branch into a Catch or Finally statement

He also lists that a Goto can cannot branch into With, For, For Each, or
SyncLock statements.
I think adding a ReTry keyword would be nice, but like you said you'd have
to watch out for an endless loop. Perhaps the ReTry could have optional
parameters to prevent that:

ReTry [[MaxRetries][,RetryDelayMs]]
I would include an optional label also, as you can have different Labels in
the Try block with different Goto's. I'm not sure how often I would have
more then a single Goto, as its not as obvious as a single goto what is
going on.

Try
TryAgain1:
Something()
TryAgain2:
SomethingElse()
Catch
If whatever Then
Goto TryAgain1
Else
Goto TryAgain2
End If
End Try


Hope this helps
Jay

Chris Dunaway said:
Ed,
In addition to the Loop that Al showed, you can use Goto within a Catch
block to go to a label in the Try Block.

Jay, is there any reason to put the label *inside* the Try instead of
outside it? Does it make any difference?

Try
TryAgain:
'Whatever
Catch
If SomeCondition Then
Goto TryAgain
EndIf
End Try


As opposed to this:

TryAgain:
Try
'Whatever
Catch
If SomeCondition Then
Goto TryAgain
EndIf
End Try
In this instance I consider Goto more of a Resume Try than an actual Goto.
;-)

I think adding a ReTry keyword would be nice, but like you said you'd have
to watch out for an endless loop. Perhaps the ReTry could have optional
parameters to prevent that:

ReTry [[MaxRetries][,RetryDelayMs]]

Just a thought


--
Chris

To send me an E-mail, remove the "[", "]", underscores ,lunchmeat, and
replace certain words in my E-Mail address.
 
Jay,

As I said, to each his own. I personally think that GoTo should have been removed from the language all together. I have seen
many, many more bad uses of GoTo than good ones over my 24 years in the profession.

Again, just my $0.02.

--
Al Reid

"It ain't what you don't know that gets you into trouble. It's what you know
for sure that just ain't so." --- Mark Twain
 
Al,
As I said, to each his own.
Yes to each their own (or is it your own)! ;-)
I have seen many, many more bad uses of GoTo
than good ones over my 24 years in the profession.
I have 24+ years also, and I suspect as many or more languages as yourself,
I'm not sure of the relevance.
I personally think that GoTo should have been removed from the language
all together.
Just out of curiosity: If the statement was called "Resume Try" would you
have an issue with it?

How about "Exit Function", "Continue", "Return", "break" or any other
Structured Programming statement that is a thinly vailed Goto do you have an
issue with them?

Please don't judge the intent of Goto in THIS INSTANCE with most other uses
of Goto.

Remember this use of the Goto is constrained by the following rules:
- A Goto can only branch from a Catch statement into the Try block of the
same statement
- A Goto can never branch out of a Finally statement
- A Goto can never branch into a Catch or Finally statement

So its not so much a Goto per se, as its a Resume Try (aka "Exit Function",
"Continue", "Return", "break")...

Just a thought
Jay

Al Reid said:
Jay,

As I said, to each his own. I personally think that GoTo should have been
removed from the language all together. I have seen
many, many more bad uses of GoTo than good ones over my 24 years in the profession.

Again, just my $0.02.

--
Al Reid

"It ain't what you don't know that gets you into trouble. It's what you know
for sure that just ain't so." --- Mark Twain

Al,
Unfortunately too many people feel that bad use of a Goto makes the Goto
bad.

I feel "correctness" is more important then any preconceived notions I may
have had about bad uses of Goto in the past.

Of course "correctness" is subjective.

Hope this helps
Jay

Al Reid said:
Jay,

Somehow, the use of the "GoTo" statement just doesn't ever seem to
come to
mind as a solution unless I am *really* stuck and can
find no other way out. For others, it seems to be the first and only choice.

To each his own.
you
know
for sure that just ain't so." --- Mark Twain

"Jay B. Harlow [MVP - Outlook]" <[email protected]> wrote in
message
Ed,
In addition to the Loop that Al showed, you can use Goto within a Catch
block to go to a label in the Try Block.

In this instance I consider Goto more of a Resume Try than an actual Goto.
;-)

Try
TryAgain:
... 'Whatever needs to be done
Catch e as exception
.... If it is the error you think you can retry then wait
Goto TryAgain
End Try

Normally I put an If around the "Resume Try" (goto) so as to avoid an
endless loop.

Something like:
Try
TryAgain:
AttemptToReadFile()
' Throw New System.IO.FileNotFoundException
Catch ex As System.IO.FileNotFoundException
If MessageBox.Show("What would you like to do?", "File not
found", MessageBoxButtons.RetryCancel, MessageBoxIcon.Question,
MessageBoxDefaultButton.Button2) = DialogResult.Retry Then
GoTo TryAgain
Else
Throw ' let error propagate up
End If
End Try

Hope this helps
Jay

Hi,
In vb6, if I had an error handler I could catch an error,
make a correction and then try it again using resume. I
want to do the same thing in vb.net.

I am trying to deal with some concurrency issues. I want
to be able to catch a error, wait a few milliseconds and
then try it again. Any help on this would be great.
Thanks ... Ed
 
Hi Jay,

You know this is very in my intrest and I did want to avoid to give my
opinion this time.
How about "Exit Function", "Continue", "Return", "break" or any other
Structured Programming statement that is a thinly vailed Goto do you have an
issue with them?

You forgot one important one in this the Select Case (Switch).

And all of those I did not like, however for those I cannot find arguments
anymore.

They have one thing in common in the way they are used in VB.net, (what a
resume try would have as well), you know that the reach is limited to the
procedure they are in.

With the Goto you are not direct sure of that.

My thought of it, however you did know that already I gues.

Cor
 
Jay,

Jay B. Harlow said:
Al,
Yes to each their own (or is it your own)! ;-)

I have 24+ years also, and I suspect as many or more languages as yourself,
I'm not sure of the relevance.

No need to compare resumes here. Suffice it to say that the relevance is that if it can be abused, I have seen it be abused.
all together.
Just out of curiosity: If the statement was called "Resume Try" would you
have an issue with it?

If there were a Resume Try that was confined to operate specifically within the confines of the scope of the Try block in qiestion,
I would not hava a problem with it.
How about "Exit Function", "Continue", "Return", "break" or any other
Structured Programming statement that is a thinly vailed Goto do you have an
issue with them?

I would not categorize structures programming constructs as "thinly vailed GoTo" statements. I do have a problem with Exit
Function/Sub since I am a proponent of the single exit point.
Please don't judge the intent of Goto in THIS INSTANCE with most other uses
of Goto.

Remember this use of the Goto is constrained by the following rules:

So its not so much a Goto per se, as its a Resume Try (aka "Exit Function",
"Continue", "Return", "break")...

Just a thought

Not a bad thought at all. My original point is that for me, and in any app that I must maintain, I avoid the use of the GoTo and
hope not to have to maintain a program that suffers from GoTo abuse.
 
Back
Top