Possible TRY...CATCH...END TRY

N

Nay Myo Aung

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/
 
O

Ollie

wouldn't it be the RESPONIBILITY of the caller to sort out the problem and
re-call the method and not group all functionality into one class i.e
encapsulate away certain data\methods ?

Ollie Riches
 
R

Robby

This is a great idea!!

We VB programmers have always had On Error Goto <label> where we could try
to fix the error and go back to the start of the block. While we can still
do this in .Net I prefer not to as I try to use the framework error handling
of Try ... Catch ... End Try. This idea offers some really great
flexibility for handling exceptions. I am surprised that they have not
mentioned anything like this in their .Net briefs.

If your listening MS, please consider this.

Robby
 
E

Elp

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?
 
G

Guest

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
 
A

Anders Norås [MCAD]

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
....

I don't think this is a good idea. There is a good reason why exceptions are
called exceptions. They only occur exceptionally.
You should not be surprised by FileNotFoundExceptions and similar in your
code. The correct way to handle the file not found issue in your example is
to do it like this:

if (File.Exists(filename)) {
// Do something
} else {
// Try another filename or something..
}

Anders Norås
http://dotnetjunkies.com/weblog/anoras
 
G

Guest

Hi,

This is true.

But in some cases, when you know it's possible some exception might be
thrown, and you have implemented code to handle it (in a catch block), you
might want to retry what you just did. In those cases, a retry keyword might
be better.

Regards,
Rakesh Rajan
 
M

Morten Wennevik

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;
}
 
C

Cor Ligthert

Nay,

Why would you endless have to catch an error is one them not more than
enough

The only thing where I can now see where it can be used is in spaghetti
code.
(And your proposal would than be a legalizing of that)

You are not the first one by the way who contributes this to the language.vb
newsgroup.

Just my thought


Cor
 
O

Ollie

this is just messy IMO

Ollie

Rakesh Rajan said:
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
 
N

Nay Myo Aung

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

In above example, we need to duplicate the code written in Try block into
sub-Try blocks with just small variations. I consider this as a bad practice
since more code duplication means, more errors and more maintenance
overhead. That's why we need a ReTry statement.

I know we can put the reusable code into Sub procedures but sometimes the
code is not big enough (or not worth the system overhead) to put it in its
own procedure.

--
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 said:
Nay,

Why would you endless have to catch an error is one them not more than
enough

The only thing where I can now see where it can be used is in spaghetti
code.
(And your proposal would than be a legalizing of that)

You are not the first one by the way who contributes this to the
language.vb newsgroup.

Just my thought


Cor


Nay Myo Aung said:
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/
 
N

Nay Myo Aung

Hi Robby,

I hope MS consider this too!

--
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/

Robby said:
This is a great idea!!

We VB programmers have always had On Error Goto <label> where we could try
to fix the error and go back to the start of the block. While we can
still do this in .Net I prefer not to as I try to use the framework error
handling of Try ... Catch ... End Try. This idea offers some really great
flexibility for handling exceptions. I am surprised that they have not
mentioned anything like this in their .Net briefs.

If your listening MS, please consider this.

Robby


Nay Myo Aung said:
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/
 
N

Nay Myo Aung

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 :))

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/
 
M

Mattias Sjögren

You can have this functionality today

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


And in VB.NET the start label can be placed somewhere inside the try
block, letting you restart from some point in the middle.



Mattias
 
N

Nay Myo Aung

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/
 
M

Mattias Sjögren

Anders,
The correct way to handle the file not found issue in your example is
to do it like this:

if (File.Exists(filename)) {

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.



Mattias
 
H

Herfried K. Wagner [MVP]

Nay Myo Aung said:
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

A "small variation" is a difference. Typically you would put the code into
a reusable method. I think the supposed 'ReTry' statement would make
maintainance of code worse and make understanding and extending code harder.
 
H

Herfried K. Wagner [MVP]

Nay Myo Aung said:
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)...

Can you post a real-life sample?!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Top