473,322 Members | 1,480 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

Possible TRY...CATCH...END TRY

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/
Nov 21 '05 #1
68 2396

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" <owNOspaMnerATnaymyoauNOspaMng.name> wrote in message
news:ui**************@TK2MSFTNGP14.phx.gbl...
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/

Nov 21 '05 #2
Elp
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?
Nov 21 '05 #3
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

"Elp" wrote:
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?

Nov 21 '05 #4
> 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
Nov 21 '05 #5
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

"Anders Norås [MCAD]" wrote:
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

Nov 21 '05 #6
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;
}

--
Happy Coding!
Morten Wennevik [C# MVP]
Nov 21 '05 #7
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" <owNOspaMnerATnaymyoauNOspaMng.name>
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/

Nov 21 '05 #8
this is just messy IMO

Ollie

"Rakesh Rajan" <Ra*********@discussions.microsoft.com> wrote in message
news:8D**********************************@microsof t.com...
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

"Elp" wrote:
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?

Nov 21 '05 #9
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" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
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" <owNOspaMnerATnaymyoauNOspaMng.name>
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/


Nov 21 '05 #10
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" <ed****@not.my.email.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

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" <owNOspaMnerATnaymyoauNOspaMng.name> wrote in message
news:ui**************@TK2MSFTNGP14.phx.gbl...
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/


Nov 21 '05 #11
Hi Rakesh,

This is great 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/

"Rakesh Rajan" <Ra*********@discussions.microsoft.com> wrote in message
news:8D**********************************@microsof t.com...
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

"Elp" wrote:
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?


Nov 21 '05 #12
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(intCurFi leTryArray))

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(intCurFi leTryArray))

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/
"Morten Wennevik" <Mo************@hotmail.com> wrote in message
news:opsifh60ukklbvpo@pbn_computer...
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;
}

--
Happy Coding!
Morten Wennevik [C# MVP]


Nov 21 '05 #13
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

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Nov 21 '05 #14
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

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Nov 21 '05 #15
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/

"Ollie" <ol**********@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
this is just messy IMO

Ollie

"Rakesh Rajan" <Ra*********@discussions.microsoft.com> wrote in message
news:8D**********************************@microsof t.com...
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

"Elp" wrote:
> 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?
>


Nov 21 '05 #16
"Nay Myo Aung" <no*****@noserver.com> schrieb:
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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #17
Look at the Eiffel Language :)

"Nay Myo Aung" <owNOspaMnerATnaymyoauNOspaMng.name> wrote in message
news:ui**************@TK2MSFTNGP14.phx.gbl...
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/

Nov 21 '05 #18
"Nay Myo Aung" <no*****@noserver.com> schrieb:
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?!

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #19
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
Nov 21 '05 #20
"Cor Ligthert" <no************@planet.nl> schrieb:
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.


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

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #21
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/
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:ek**************@TK2MSFTNGP15.phx.gbl...
"Nay Myo Aung" <no*****@noserver.com> schrieb:
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?!

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #22
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/...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/

"Darren Barrick" <Da***********@ZenZero.co.uk> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
Look at the Eiffel Language :)

"Nay Myo Aung" <owNOspaMnerATnaymyoauNOspaMng.name> wrote in message
news:ui**************@TK2MSFTNGP14.phx.gbl...
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/


Nov 21 '05 #23
>
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.

I mean with that you cannot catch everything

Cor
Nov 21 '05 #24
"Nay Myo Aung" <no*****@noserver.com> schrieb:
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
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #25


"Nay Myo Aung" wrote:
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(intCurFi leTryArray))

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(intCurFi leTryArray))

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/
"Morten Wennevik" <Mo************@hotmail.com> wrote in message
news:opsifh60ukklbvpo@pbn_computer...
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;
}

--
Happy Coding!
Morten Wennevik [C# MVP]


Nov 21 '05 #26
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]
- mv*@spam.guard.caspershouse.com

"Nay Myo Aung" <no*****@noserver.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
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/

"Ollie" <ol**********@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
this is just messy IMO

Ollie

"Rakesh Rajan" <Ra*********@discussions.microsoft.com> wrote in message
news:8D**********************************@microsof t.com...
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

"Elp" wrote:

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



Nov 21 '05 #27
> 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/

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:OD**************@TK2MSFTNGP10.phx.gbl... "Nay Myo Aung" <no*****@noserver.com> schrieb:
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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #28
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]" <hi***************@gmx.at> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... "Nay Myo Aung" <no*****@noserver.com> schrieb:
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
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #29

"Nay Myo Aung" <no*****@noserver.com> wrote

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

Nov 21 '05 #30
"Nay Myo Aung" wrote:
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.
Nov 21 '05 #31
> 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/
"Daniel Jin" <Da*******@discussions.microsoft.com> wrote in message
news:34**********************************@microsof t.com...

"Nay Myo Aung" wrote:
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(intCurFi leTryArray))

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(intCurFi leTryArray))

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/
"Morten Wennevik" <Mo************@hotmail.com> wrote in message
news:opsifh60ukklbvpo@pbn_computer...
> 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;
> }
>
> --
> Happy Coding!
> Morten Wennevik [C# MVP]


Nov 21 '05 #32
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" <no*****@noserver.com> 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]" <hi***************@gmx.at> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
"Nay Myo Aung" <no*****@noserver.com> schrieb:
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
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>


Nov 21 '05 #33

"Nay Myo Aung" <no*****@noserver.com> wrote in
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
Nov 21 '05 #34

"Nay Myo Aung" <no*****@noserver.com> schrieb:
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? :)


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

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #35
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/
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:ui**************@TK2MSFTNGP14.phx.gbl...
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]
- mv*@spam.guard.caspershouse.com

"Nay Myo Aung" <no*****@noserver.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
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/

"Ollie" <ol**********@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
this is just messy IMO

Ollie

"Rakesh Rajan" <Ra*********@discussions.microsoft.com> wrote in message
news:8D**********************************@microsof t.com...
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

"Elp" wrote:

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



Nov 21 '05 #36
"Nay Myo Aung" <no*****@noserver.com> schrieb:
'##### 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? :)


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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #37
"Daniel Jin" <Da*******@discussions.microsoft.com> schrieb:
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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #38
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/

"Cor Ligthert" <no************@planet.nl> wrote in message
news:uc**************@TK2MSFTNGP14.phx.gbl...
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" <no*****@noserver.com>

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]" <hi***************@gmx.at> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
"Nay Myo Aung" <no*****@noserver.com> schrieb:
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
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>



Nov 21 '05 #39
EXACTLY as my first post states, responsiblity, encapsualtion.....

Does this remind you of OO prinicples at all?
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
"Nay Myo Aung" <no*****@noserver.com> schrieb:
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
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

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

Yes, you need to catch exceptions when working with files, but you shouldn't
use try-catch as a lazy way to check if the files exists.

From the design guidelines for application developers (MSDN):
a.. All code paths that result in an exception should provide a method to
check for success without throwing an exception. For example, to avoid a
FileNotFoundException you can call File.Exists. This might not always be
possible, but the goal is that under normal execution no exceptions should
be thrown.

Anders Norås
http://dotnetjunkies.com/weblog/anoras/
Nov 21 '05 #41
>
For example, you specify another server name until a connection can be
established. You'll have to declare 'i' outside the 'Try...Catch'.

When you retrieve the server names from the database, there's no need to
define i for counter.

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

Consider tens of Try...catch statments in many procedures and in many
objects. You'll feel the bigger impact.

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/
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl... "Nay Myo Aung" <no*****@noserver.com> schrieb:
'##### 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? :)


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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #42
Totally agree, throwing or more precisely generating an exception is a time
consuming task and therefore should be avoided. we have all been told to
avoid code like this:
try
{
system.object obj = 1;
string val = (string)obj;
}
catch(System.Exception)
{
......
}

......

Ollie Riches
"Anders Norås [MCAD]" <an**********@objectware.no> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
That's true, but it doesn't mean that you don't need to use 'Try...Catch' when attempting to open a file. Yes, you need to catch exceptions when working with files, but you

shouldn't use try-catch as a lazy way to check if the files exists.

From the design guidelines for application developers (MSDN):
a.. All code paths that result in an exception should provide a method to
check for success without throwing an exception. For example, to avoid a
FileNotFoundException you can call File.Exists. This might not always be
possible, but the goal is that under normal execution no exceptions should
be thrown.

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

Nov 21 '05 #43
>>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.
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).

Who said you should hard code them? However this is not the answer on your
question accoording to your pevious sample.

Cor
Nov 21 '05 #44
> 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 :)
I like syntactic sugar too when it adds value, like the 'using' or 'lock'
statements in C#. they help you avoid problems that otherwise might happen
if you are not too careful. but I don't see retry as being useful enough,
and it certainly can be easily abused in writing badly structured program
logic.
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.
Retrying what you did with variation sounds very much to me like controlling
the program flow. for example look at the following pseudo-code

try
{
open file and do stuff
}
catch( filenotfoundexception )
{
create file
retry;
}

when it should really be written as

if( not file exist )
create file
open file and do stuff

I understand that there are certain cases where something like retry might
indeed be useful, but i think these situations are rare enough that it
doesn't justify a new keyword being introduced. especially when existing
language construct already supports it.

--
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/
"Daniel Jin" <Da*******@discussions.microsoft.com> wrote in message
news:34**********************************@microsof t.com...


"Nay Myo Aung" wrote:
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(intCurFi leTryArray))

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(intCurFi leTryArray))

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/
"Morten Wennevik" <Mo************@hotmail.com> wrote in message
news:opsifh60ukklbvpo@pbn_computer...
> 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;
> }
>
> --
> Happy Coding!
> Morten Wennevik [C# MVP]


Nov 21 '05 #45
Nay,
You may want to use the Suggestion link at the VB.NET 2005 Product Feedback
Center http://lab.msdn.microsoft.com/vs2005/, however I'm not sure how high
a consideration it will get as...

VB.NET already includes it (as Mattias suggests), its been there since
VB.NET 2002. A Number of developers don't like it uses the "Goto" keyword,
however in *this* instance it is only allowed to go from the Catch Block to
the Try Block, so I don't have a big problem with it. Let me restate that in
VB.NET a label in a Try Block can only be reached from an associated Catch
block! In other words I am not referring to uses of Goto outside of a Catch
block or use of a Goto to exit a Try/Catch statement!

Here is how "ReTry" is currently implemented in VB.NET:
Try Retry:
'...something

Catch e as FileNotFoundException

'correct the error and then Goto Retry
Catch e2 as DirectoryNotFoundException

'correct the error and then Goto Retry
Catch e3 as DriveNotFoundException

'correct the error and then Goto Retry
Catch '<< catch 'unknown' error

'log the error

Finally

End Try
"ReTry" as the others have pointed out like any language construct can be
used for good as equally well as evil. I would expect any of my developers
to document very well the actual *need* for ReTry in the specific context. I
normally limit it use to prompting the user:
Try Retry:
'...something

Catch e as FileNotFoundException

If MessageBox.Show("File does not exit!",
Application.ProductName, _
MessageBoxButtons.RetryCancel, MessageBoxIcon.Question,
_
MessageBoxDefaultButton.Button2) = DialogResult.Retry
Then
GoTo retry
End If

End Try
Hope this helps
Jay

"Nay Myo Aung" <owNOspaMnerATnaymyoauNOspaMng.name> wrote in message
news:ui**************@TK2MSFTNGP14.phx.gbl... 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/

Nov 21 '05 #46
"Herfried K. Wagner [MVP]" wrote:
"Daniel Jin" <Da*******@discussions.microsoft.com> schrieb:
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'.


the point I was trying to make is that something like retry will have such
rare legitimate uses that I don't think add a new keyword justifies it,
especially when it's already supported. and in language design, if you add
new constructs for every little thing you can think of, you'd end up with a
mess on your hand.
Nov 21 '05 #47
"Daniel Jin" <Da*******@discussions.microsoft.com> schrieb:
the point I was trying to make is that something like retry will have such
rare legitimate uses that I don't think add a new keyword justifies it,
especially when it's already supported. and in language design, if you
add
new constructs for every little thing you can think of, you'd end up with
a
mess on your hand.


Full ACK. That's why I don't see a benefit in adding 'ReTry'.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #48
"Anders Norås [MCAD]" <an**********@objectware.no> schrieb:
That's true, but it doesn't mean that you don't need to use 'Try...Catch'
when attempting to open a file.

Yes, you need to catch exceptions when working with files, but you
shouldn't use try-catch as a lazy way to check if the files exists.

From the design guidelines for application developers (MSDN):
a.. All code paths that result in an exception should provide a method to
check for success without throwing an exception. For example, to avoid a
FileNotFoundException you can call File.Exists. This might not always be
possible, but the goal is that under normal execution no exceptions should
be thrown.


ACK.

I prefer:

\\\

' Move this line inside the 'Try' if it can throw an exception.
If File.Exists(...) Then
Try

' Access the file.
Catch
...
Finally
...
End Try
End If
///

.... over...

\\\
If File.Exists(...) Then

' Access the file.
End If
///

.... and...

\\\
Try

' Access the file.
Catch
...
Finally
...
End Try
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #49
And how exactly would you implement those variations when using your
proposed ReTry statement?

Stefan

"Nay Myo Aung" <no*****@noserver.com> wrote in message
news:e2**************@TK2MSFTNGP14.phx.gbl...
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/
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in message news:ui**************@TK2MSFTNGP14.phx.gbl...
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]
- mv*@spam.guard.caspershouse.com

"Nay Myo Aung" <no*****@noserver.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
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/

"Ollie" <ol**********@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
this is just messy IMO

Ollie

"Rakesh Rajan" <Ra*********@discussions.microsoft.com> wrote in message
news:8D**********************************@microsof t.com...
> 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
>
> "Elp" wrote:
>
> > 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?
> >



Nov 21 '05 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.