Possible TRY...CATCH...END TRY

[Cor Ligthert]

Mattias,

Checking File.Exists is no excuse for not being prepared to hande a
FileNotFoundException. Just because a file exists at one point doesn't
mean it will still exist when you try to do something with it.

You cannot catch that the power goes down is almost always my simplified
answer on this.

Is up to you if you agree that with me



Cor

 

[Herfried K. Wagner [MVP]]

You cannot catch that the power goes down is almost always my simplified
answer on this.

That's true, but it doesn't mean that you don't need to use 'Try...Catch'
when attempting to open a file.

 

[Nay Myo Aung]

Hi Herfried,

For instance, you might want to try to check which file in a list of files
(probably retrieved from the database) actually exists or check which server
from a list of servers that your program can successfully connect or you
might want to retry connect to a network 10 times with specific intervals
(that can be done with Labels and GoTo but then again it is not as elegant
as ReTry, isn't it?)...etc.

I hope it helps.

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

 

[Nay Myo Aung]

Hi Darren,

I just looked at the exception handling chapter of Eiffel for .NET language
manual. That's what I'm exactly proposing!

This is the link:
http://docs.eiffel.com/eiffelstudio...guage/20_language/60_exception_mechanism.html

Thanks for pointing me out!!

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

Look at the Eiffel Language

Hi All!

I think I discovered a possible improvement on .NET Framwork's
TRY...CATCH...END TRY statement. I guess most developers might also have
been discovered that at some point in their .NET development process but
continued to ignore the problem due to their workloads.

The word is RETRY.

Consider the following...

Try

'...something

Catch e as FileNotFoundException

'correct the error and then
ReTry

Catch e2 as DirectoryNotFoundException

'correct the error and then
ReTry

Catch e3 as DriveNotFoundException

'correct the error and then
ReTry

Catch '<< catch 'unknown' error

'log the error

Finally

End Try

We .NET programmers could use the keyword RETRY in the any of the Catch
block to re-execute the code in Try block. If there's another exception
thrown, we can evaulate that exception in one of the many Catch blocks
until it reached to the 'unkown' exception.

So, I propose that a new keyword ReTry should be incorporated in the .NET
Framework 2 as an improvement.

Feel free to feedback on the idea...

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

 

[Cor Ligthert]

That's true, but it doesn't mean that you don't need to use 'Try...Catch'
when attempting to open a file.

I mean with that you cannot catch everything

Cor

 

[Herfried K. Wagner [MVP]]

For instance, you might want to try to check which file in a list of files
(probably retrieved from the database) actually exists or check which
server from a list of servers that your program can successfully connect
or you might want to retry connect to a network 10 times with specific
intervals (that can be done with Labels and GoTo but then again it is not
as elegant as ReTry, isn't it?)...etc.

For me, that's a typical example of encapsulating the functionality in a
separate method:

\\\
Dim Connection As...
For i As Integer = 1 To MaxTrials
Try
Connection = ConnectToServer(...)
Exit For
Catch
Thread.Sleep(1000)
End Try
Next i
If Not Connection Is Nothing Then
...
End If
///

 

[Nay Myo Aung]

A "small variation" is a difference. Typically you would put the code

into a reusable method.

For instance, you might have a task that span 2 lines of code in a Try
block. One of the lines has a variable (such as server name to connect to)
that will vary based on exceptions. Do you think it is a good idea to put
that 2 lines of code into a sub procedure and have nested Try blocks to
retry the task repeatdly when exceptions are thrown? I mean does it worth
the system overhead created by sub procedures? What about the number of
lines of code must be written compared to using ReTry?

I think the supposed 'ReTry' statement would make maintainance of code
worse and make understanding and extending code harder.

Could you give me an example?

IMO, you just use one keyword "ReTry" and the corresponding Try block will
be re-executed. Simple and clean.

Cheers

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

 

[Guest]

Hi Morten,

Yes, I know that currently this can be achieved through the use of Labels
and Goto statement. But "ReTry" statement is not currently supported (hence
a proposal )

well, if such a keyword is introduced, it'd compile down to probably the
exact same IL as the goto variant that it supports already. it'd be nothing
more than syntactic sugar so to speak. and I really don't see enough use to
justify adding a whole new keyword.

not to mention generally speaking, using exceptions to control program flow
is just a very bad idea.

From the following two code segments, which one do you think is more
elegant?

******* CODE BLOCK #1 ***********

Dim strArrayFileTryList(5) as String
strArrayFileTryList(0) = "file1.txt"
strArrayFileTryList(1) = "file2.txt"
strArrayFileTryList(2) = "file3.txt"
strArrayFileTryList(3) = "file4.txt"
strArrayFileTryList(4) = "file5.txt"

Dim intCurFileTryArray as Integer

Try

SomethingToDoWithFile(strArrayFileTryList(intCurFileTryArray))

Catch e as Exception1

intCurFileTryArray += 1

If intCurFileTryArray > strArrayFileTryList.Length Then
MessageBox.Show ("Cannot open any of the files")
Else
ReTry
End If

Catch

End Try

******* END CODE BLOCK #1 ***********

******* CODE BLOCK #2 ***********

Dim strArrayFileTryList(5) as String
strArrayFileTryList(0) = "file1.txt"
strArrayFileTryList(1) = "file2.txt"
strArrayFileTryList(2) = "file3.txt"
strArrayFileTryList(3) = "file4.txt"
strArrayFileTryList(4) = "file5.txt"

Dim intCurFileTryArray as Integer

ReStart:

Try

SomethingToDoWithFile(strArrayFileTryList(intCurFileTryArray))

Catch e as Exception1

intCurFileTryArray += 1

If intCurFileTryArray > strArrayFileTryList.Length Then
MessageBox.Show ("Cannot open any of the files")
Else
Goto ReStart:
End If

Catch

End Try

******* END CODE BLOCK #2 ***********

Besides, Goto statement in this example appear to be "segmented" when
reading the flow of the code. IMO, it makes more sense to "ReTry" then ask
to "go somewhere". This is especially true when you have enormous
Try...Catch segements in one procedure because if we use GoTo statement, we
have to label them "ReTry1", "ReTry2" or "ReTry<<TaskName>>" which I think
distract the programmer when he/she reads the flow of the code. What do you
think??

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

 

[Nicholas Paldino [.NET/C# MVP]]

Nay,

Actually, you can put the try/catch in a loop, counting each time you
cycle through it. When you hit the nth time, you just rethrow the
exception, instead of swallowing it.

Nesting it 10 times would be ridiculous.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi Ollie,

Without ReTry, you need to duplicate the code from Try block with small
variations in nested-Try blocks. For example, using the current Framework,
you might encounter a situation where you need to write about 10
nested-Try blocks to execute for the same code (with only small variation
for each exception)...

Which is more messier?

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

this is just messy IMO

Ollie

 

[Nay Myo Aung]

ok, here is my code example of trying out for different servers (retrieved
from the database)...

'##### Trying out different servers... #####

Try
Dim objConnection as FakeConnection
objConnection = New FakeConnection
objConnection .ConnectToServer(objDataReader("ServerName"))
Catch
If objDataReader.Read() Then ReTry
Finally
If Not objConnection.Connected Then
MessageBox.Show("Cannot connect to any of the servers")
End If
End Try

'##### END CODE #####


Below is your way of repeatedly trying for the same server...

\\\
Dim Connection As...
For i As Integer = 1 To MaxTrials
Try
Connection = ConnectToServer(...)
Exit For
Catch
Thread.Sleep(1000)
End Try
Next i
If Not Connection Is Nothing Then
...
End If
///

And below is my proposed way...

'##### Retrying for same server... #####

Dim i as integer

Try
ConnectToServer(objDataReader("ServerName"))
Catch
Thread.Sleep(1000)
i += 1
if i < 10 then ReTry
Finally
If Not Connection Is Nothing Then
MessageBox.Show("Connection Timed Out")
End If
End Try

'##### END CODE #####

Which one is more elegant? Which one is more readable? Which one is more
understandable/predictable?

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

 

[Guest]

Hi Cor,

Actually, it is not endless. We could put counters or we could have
something like ReTry(3) for 3 retries, as pointed out by Rakesh Rajan.

The main idea is to eliminate the need to rewrite the code that is already
written in the Try block with only a small variation (small enough to be
defined through variables).

For instance...

Try
<<TaskA>>
Catch

Try
<<TaskA with small variation>>
Catch

Try
<<TaskA with another small variation>>
Catch

Try
<<TaskA with yet another small variation>>
Catch

End Try

End Try

End Try

End Try

you are already violating what not to do with exceptions when you write code
blocks as such. retry will only facilitate such bad practice.

 

[Larry Serflaten]

From the following two code segments, which one do you think is more
elegant?

Why only two submissions:


Do While ListIndex < FileList.Count
If ProcessCompleted(FileList(ListIndex)) Then Exit Do
ListIndex += 1
Loop

Here the called process returns a Boolean True on success, and
leaves the error trapping to the actual file handling code....

The point is that a little different design may do the job in a more
straight forward manner. As others indicated, you are advocating
the opportunity to add hard to follow (recursive) logic. Why not
just use a simpler design?

LFS

 

[Nay Myo Aung]

well, if such a keyword is introduced, it'd compile down to probably the

exact same IL as the goto variant that it supports already. it'd be
nothing
more than syntactic sugar so to speak. and I really don't see enough use
to
justify adding a whole new keyword.

Yes but I would careless about how it is displayed in the IL. What I would
care more is how much the language I use to program resembles to our
everyday language. If that "syntactic sugar" than that's what I like

not to mention generally speaking, using exceptions to control program
flow
is just a very bad idea.

I'm not proposing to use exceptions to control the program flow. When you
use ReTry, you basically just "retrying" what you just did in the
corresponding Try block with some variations. It is totally different
analogy from GoTo statement. So I don't thnk it is such a bad idea.

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

Hi Morten,

Yes, I know that currently this can be achieved through the use of Labels
and Goto statement. But "ReTry" statement is not currently supported
(hence
a proposal )

well, if such a keyword is introduced, it'd compile down to probably the
exact same IL as the goto variant that it supports already. it'd be
nothing
more than syntactic sugar so to speak. and I really don't see enough use
to
justify adding a whole new keyword.

not to mention generally speaking, using exceptions to control program
flow
is just a very bad idea.

From the following two code segments, which one do you think is more
elegant?

******* CODE BLOCK #1 ***********

Dim strArrayFileTryList(5) as String
strArrayFileTryList(0) = "file1.txt"
strArrayFileTryList(1) = "file2.txt"
strArrayFileTryList(2) = "file3.txt"
strArrayFileTryList(3) = "file4.txt"
strArrayFileTryList(4) = "file5.txt"

Dim intCurFileTryArray as Integer

Try

SomethingToDoWithFile(strArrayFileTryList(intCurFileTryArray))

Catch e as Exception1

intCurFileTryArray += 1

If intCurFileTryArray > strArrayFileTryList.Length Then
MessageBox.Show ("Cannot open any of the files")
Else
ReTry
End If

Catch

End Try

******* END CODE BLOCK #1 ***********

******* CODE BLOCK #2 ***********

Dim strArrayFileTryList(5) as String
strArrayFileTryList(0) = "file1.txt"
strArrayFileTryList(1) = "file2.txt"
strArrayFileTryList(2) = "file3.txt"
strArrayFileTryList(3) = "file4.txt"
strArrayFileTryList(4) = "file5.txt"

Dim intCurFileTryArray as Integer

ReStart:

Try

SomethingToDoWithFile(strArrayFileTryList(intCurFileTryArray))

Catch e as Exception1

intCurFileTryArray += 1

If intCurFileTryArray > strArrayFileTryList.Length Then
MessageBox.Show ("Cannot open any of the files")
Else
Goto ReStart:
End If

Catch

End Try

******* END CODE BLOCK #2 ***********

Besides, Goto statement in this example appear to be "segmented" when
reading the flow of the code. IMO, it makes more sense to "ReTry" then
ask
to "go somewhere". This is especially true when you have enormous
Try...Catch segements in one procedure because if we use GoTo statement,
we
have to label them "ReTry1", "ReTry2" or "ReTry<<TaskName>>" which I
think
distract the programmer when he/she reads the flow of the code. What do
you
think??

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

Hi Nay Myo Aung,

You can have this functionality today

int counter = 0;
start:;
try
{
File.Open("dummy", FileMode.Open);
}
catch
{
counter++;
if(counter < 5)
goto start;
}

 

[Cor Ligthert]

Nay,

How do you change the servername with your code, the sample from Herfried
seems for me more effective for this, you only have to set the servernames
in an array and use a for each loop then.

Cor

Nay Myo Aung" <[email protected]>

ok, here is my code example of trying out for different servers (retrieved
from the database)...

'##### Trying out different servers... #####

Try
Dim objConnection as FakeConnection
objConnection = New FakeConnection
objConnection .ConnectToServer(objDataReader("ServerName"))
Catch
If objDataReader.Read() Then ReTry
Finally
If Not objConnection.Connected Then
MessageBox.Show("Cannot connect to any of the servers")
End If
End Try

'##### END CODE #####


Below is your way of repeatedly trying for the same server...

\\\
Dim Connection As...
For i As Integer = 1 To MaxTrials
Try
Connection = ConnectToServer(...)
Exit For
Catch
Thread.Sleep(1000)
End Try
Next i
If Not Connection Is Nothing Then
...
End If
///

And below is my proposed way...

'##### Retrying for same server... #####

Dim i as integer

Try
ConnectToServer(objDataReader("ServerName"))
Catch
Thread.Sleep(1000)
i += 1
if i < 10 then ReTry
Finally
If Not Connection Is Nothing Then
MessageBox.Show("Connection Timed Out")
End If
End Try

'##### END CODE #####

Which one is more elegant? Which one is more readable? Which one is more
understandable/predictable?

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

 

[Herfried K. Wagner [MVP]]

For instance, you might have a task that span 2 lines of code in a Try
block. One of the lines has a variable (such as server name to connect to)
that will vary based on exceptions. Do you think it is a good idea to put
that 2 lines of code into a sub procedure and have nested Try blocks to
retry the task repeatdly when exceptions are thrown? I mean does it worth
the system overhead created by sub procedures? What about the number of
lines of code must be written compared to using ReTry?


Could you give me an example?

You showed a simple example where 'ReTry' may be useful (although I don't
see the advantages over the traditional solutions). Imagine more complex
scenarios where more complex conditions for a retry are used.

IMO, you just use one keyword "ReTry" and the corresponding Try block will
be re-executed. Simple and clean.

I don't think so. 'Try' is not supposed to be a loop block. There are
other, specialized language constructs for writing loops, and their usage is
preferred.

Just my 2 Euro cents again...

 

[Larry Serflaten]

For instance...

Can you provide a more concrete example? With what
you provided, I would want to ask, what makes you think
a 'small variation' would work? Because, if you answer that,
my next question would be why don't you test for that, before
you call on TaskA?

In other words, (for what you offered) determine ahead of time,
which variation will succeed, and use that....

A concrete example would indicate if that could be attempted
(or not).

LFS

 

[Nay Myo Aung]

Hi Nicholas,

When I say 10 nested time, I didn't mean I would do it for the counter. 10
nested Try blocks with small variation of code that will try to do the task
differently for different exceptions.

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

Nay,

Actually, you can put the try/catch in a loop, counting each time you
cycle through it. When you hit the nth time, you just rethrow the
exception, instead of swallowing it.

Nesting it 10 times would be ridiculous.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi Ollie,

Without ReTry, you need to duplicate the code from Try block with small
variations in nested-Try blocks. For example, using the current
Framework, you might encounter a situation where you need to write about
10 nested-Try blocks to execute for the same code (with only small
variation for each exception)...

Which is more messier?

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

this is just messy IMO

Ollie

Hi,

Maybe a facility something like
Retry(2)
for retrying 2 times might help.

Of course, the call to Retry should be specific for the exception type.

Regards,
Rakesh Rajan

:

On Fri, 3 Dec 2004 22:36:16 +1300, Nay Myo Aung wrote:

We .NET programmers could use the keyword RETRY in the any of the
Catch
block to re-execute the code in Try block. If there's another
exception
thrown, we can evaulate that exception in one of the many Catch
blocks
until
it reached to the 'unkown' exception.

So, I propose that a new keyword ReTry should be incorporated in
the
.NET
Framework 2 as an improvement.

The first thing that catched my eye when i saw your idea is that it
would
be dead easy to enter an endless loop with this. Retry again and
again
without any way to stop this. So you would need to add a counter in
each
of
your catch block to check if this block is not being executed
endlessly.
Quite messy, isn't it?

 

[Herfried K. Wagner [MVP]]

'##### Trying out different servers... #####

Try
Dim objConnection as FakeConnection
objConnection = New FakeConnection
objConnection .ConnectToServer(objDataReader("ServerName"))
Catch
If objDataReader.Read() Then ReTry
Finally
If Not objConnection.Connected Then
MessageBox.Show("Cannot connect to any of the servers")
End If
End Try

'##### END CODE #####


Below is your way of repeatedly trying for the same server...


And below is my proposed way...

'##### Retrying for same server... #####

Dim i as integer

Try
ConnectToServer(objDataReader("ServerName"))
Catch
Thread.Sleep(1000)
i += 1
if i < 10 then ReTry
Finally
If Not Connection Is Nothing Then
MessageBox.Show("Connection Timed Out")
End If
End Try

'##### END CODE #####

Which one is more elegant? Which one is more readable? Which one is more
understandable/predictable?

Imagine the part in 'Try' to be "slightly different" for every "trial". For
example, you specify another server name until a connection can be
established. You'll have to declare 'i' outside the 'Try...Catch'.

To make a conclusion: I can only see minimal benefit in some simple cases
for a 'ReTry' statement.

 

[Herfried K. Wagner [MVP]]

well, if such a keyword is introduced, it'd compile down to probably the
exact same IL as the goto variant that it supports already. it'd be
nothing
more than syntactic sugar so to speak. and I really don't see enough use
to
justify adding a whole new keyword.

The IL part is not a valid argument that stands against adding 'ReThrow'.
With the same argument, 'If...Then' and loops are not necessary, because
they compile down to the same IL code you can write using 'GoTo'.

not to mention generally speaking, using exceptions to control program
flow
is just a very bad idea.

ACK.

 

[Nay Myo Aung]

Hi Cor,

I'm using OleDbDataReader object as an example for looping through the
server names table. Server names are retrieved from the database (or XML
file) (I for one never hard-code them in the array).

Try
Dim objConnection as FakeConnection
objConnection = New FakeConnection
objConnection .ConnectToServer(objDataReader("ServerName"))
Catch
If objDataReader.Read() Then ReTry
Finally
If Not objConnection.Connected Then
MessageBox.Show("Cannot connect to any of the servers")
End If
End Try

In above example, objDataReader("ServerName") grab the "ServerName" field of
current row.

objDataReader.Read() moves to the next record position and ReTry the code in
Try block.

Thus, if an exception occur, it will move to the next record and try again
until all the records has been tried.

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

Nay,

How do you change the servername with your code, the sample from Herfried
seems for me more effective for this, you only have to set the servernames
in an array and use a for each loop then.

Cor

Nay Myo Aung" <[email protected]>

ok, here is my code example of trying out for different servers
(retrieved from the database)...

'##### Trying out different servers... #####

Try
Dim objConnection as FakeConnection
objConnection = New FakeConnection
objConnection .ConnectToServer(objDataReader("ServerName"))
Catch
If objDataReader.Read() Then ReTry
Finally
If Not objConnection.Connected Then
MessageBox.Show("Cannot connect to any of the servers")
End If
End Try

'##### END CODE #####


Below is your way of repeatedly trying for the same server...

\\\
Dim Connection As...
For i As Integer = 1 To MaxTrials
Try
Connection = ConnectToServer(...)
Exit For
Catch
Thread.Sleep(1000)
End Try
Next i
If Not Connection Is Nothing Then
...
End If
///

And below is my proposed way...

'##### Retrying for same server... #####

Dim i as integer

Try
ConnectToServer(objDataReader("ServerName"))
Catch
Thread.Sleep(1000)
i += 1
if i < 10 then ReTry
Finally
If Not Connection Is Nothing Then
MessageBox.Show("Connection Timed Out")
End If
End Try

'##### END CODE #####

Which one is more elegant? Which one is more readable? Which one is more
understandable/predictable?

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

For instance, you might want to try to check which file in a list of
files (probably retrieved from the database) actually exists or check
which server from a list of servers that your program can successfully
connect or you might want to retry connect to a network 10 times with
specific intervals (that can be done with Labels and GoTo but then
again it is not as elegant as ReTry, isn't it?)...etc.

For me, that's a typical example of encapsulating the functionality in a
separate method:

\\\
Dim Connection As...
For i As Integer = 1 To MaxTrials
Try
Connection = ConnectToServer(...)
Exit For
Catch
Thread.Sleep(1000)
End Try
Next i
If Not Connection Is Nothing Then
...
End If
///