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/

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:uifBpxR2EHA.3452@TK2MSFTNGP14.phx.gbl...[color=blue]
> 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/
>[/color]

On Fri, 3 Dec 2004 22:36:16 +1300, Nay Myo Aung wrote:
[color=blue]
> 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.[/color]

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?

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:
[color=blue]
> On Fri, 3 Dec 2004 22:36:16 +1300, Nay Myo Aung wrote:
>[color=green]
> > 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.[/color]
>
> 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?
>[/color]

> I think I discovered a possible improvement on .NET Framwork's[color=blue]
> 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
> ....[/color]

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

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:
[color=blue][color=green]
> > 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
> > ....[/color]
>
> 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
>
>
>[/color]

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]

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>
[color=blue]
> 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/
>[/color]

this is just messy IMO

Ollie

"Rakesh Rajan" <RakeshRajan@discussions.microsoft.com> wrote in message
news:8DEF66C7-06FD-4564-8146-C2C9C0A188FE@microsoft.com...[color=blue]
> 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:
>[color=green]
> > On Fri, 3 Dec 2004 22:36:16 +1300, Nay Myo Aung wrote:
> >[color=darkred]
> > > We .NET programmers could use the keyword RETRY in the any of the[/color][/color][/color]
Catch[color=blue][color=green][color=darkred]
> > > block to re-execute the code in Try block. If there's another[/color][/color][/color]
exception[color=blue][color=green][color=darkred]
> > > thrown, we can evaulate that exception in one of the many Catch blocks[/color][/color][/color]
until[color=blue][color=green][color=darkred]
> > > it reached to the 'unkown' exception.
> > >
> > > So, I propose that a new keyword ReTry should be incorporated in the[/color][/color][/color]
..NET[color=blue][color=green][color=darkred]
> > > Framework 2 as an improvement.[/color]
> >
> > The first thing that catched my eye when i saw your idea is that it[/color][/color]
would[color=blue][color=green]
> > 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[/color][/color]
of[color=blue][color=green]
> > your catch block to check if this block is not being executed endlessly.
> > Quite messy, isn't it?
> >[/color][/color]

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" <notmyfirstname@planet.nl> wrote in message
news:%2331sudS2EHA.1408@TK2MSFTNGP10.phx.gbl...[color=blue]
> 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>
>[color=green]
>> 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/
>>[/color]
>
>[/color]

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" <edmund@not.my.email.com> wrote in message
news:%23wwHm7R2EHA.1300@TK2MSFTNGP14.phx.gbl...[color=blue]
>
> 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:uifBpxR2EHA.3452@TK2MSFTNGP14.phx.gbl...[color=green]
>> 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/
>>[/color]
>
>[/color]

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" <RakeshRajan@discussions.microsoft.com> wrote in message
news:8DEF66C7-06FD-4564-8146-C2C9C0A188FE@microsoft.com...[color=blue]
> 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:
>[color=green]
>> On Fri, 3 Dec 2004 22:36:16 +1300, Nay Myo Aung wrote:
>>[color=darkred]
>> > 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.[/color]
>>
>> 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?
>>[/color][/color]

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" <MortenWennevik@hotmail.com> wrote in message
news:opsifh60ukklbvpo@pbn_computer...[color=blue]
> 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][/color]

[color=blue]
>You can have this functionality today
>
>int counter = 0;
>start:;
>try
>{
> File.Open("dummy", FileMode.Open);
>}
>catch
>{
> counter++;
> if(counter < 5)
> goto start;
>}[/color]

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.

Anders,
[color=blue]
>The correct way to handle the file not found issue in your example is
>to do it like this:
>
>if (File.Exists(filename)) {[/color]

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.

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" <ollie_riches@hotmail.com> wrote in message
news:%23DVXcDT2EHA.2876@TK2MSFTNGP12.phx.gbl...[color=blue]
> this is just messy IMO
>
> Ollie
>
> "Rakesh Rajan" <RakeshRajan@discussions.microsoft.com> wrote in message
> news:8DEF66C7-06FD-4564-8146-C2C9C0A188FE@microsoft.com...[color=green]
>> 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:
>>[color=darkred]
>> > 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[/color][/color]
> Catch[color=green][color=darkred]
>> > > block to re-execute the code in Try block. If there's another[/color][/color]
> exception[color=green][color=darkred]
>> > > thrown, we can evaulate that exception in one of the many Catch
>> > > blocks[/color][/color]
> until[color=green][color=darkred]
>> > > it reached to the 'unkown' exception.
>> > >
>> > > So, I propose that a new keyword ReTry should be incorporated in the[/color][/color]
> .NET[color=green][color=darkred]
>> > > Framework 2 as an improvement.
>> >
>> > The first thing that catched my eye when i saw your idea is that it[/color][/color]
> would[color=green][color=darkred]
>> > 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[/color][/color]
> of[color=green][color=darkred]
>> > your catch block to check if this block is not being executed
>> > endlessly.
>> > Quite messy, isn't it?
>> >[/color][/color]
>
>[/color]

"Nay Myo Aung" <noemail@noserver.com> schrieb:[color=blue]
> 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[/color]

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

Look at the Eiffel Language :)

"Nay Myo Aung" <owNOspaMnerATnaymyoauNOspaMng.name> wrote in message
news:uifBpxR2EHA.3452@TK2MSFTNGP14.phx.gbl...[color=blue]
> 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/
>[/color]

"Nay Myo Aung" <noemail@noserver.com> schrieb:[color=blue]
> 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)...[/color]

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

Mattias,
[color=blue]
> 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.[/color]

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

"Cor Ligthert" <notmyfirstname@planet.nl> schrieb:[color=blue][color=green]
>> 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.[/color]
>
> You cannot catch that the power goes down is almost always my simplified
> answer on this.[/color]

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

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]" <hirf-spam-me-here@gmx.at> wrote in message
news:ekQ1GVT2EHA.1860@TK2MSFTNGP15.phx.gbl...[color=blue]
> "Nay Myo Aung" <noemail@noserver.com> schrieb:[color=green]
>> 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)...[/color]
>
> 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/>[/color]

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" <DarrenBarrick@ZenZero.co.uk> wrote in message
news:%23LteBUT2EHA.3616@TK2MSFTNGP11.phx.gbl...[color=blue]
> Look at the Eiffel Language :)
>
> "Nay Myo Aung" <owNOspaMnerATnaymyoauNOspaMng.name> wrote in message
> news:uifBpxR2EHA.3452@TK2MSFTNGP14.phx.gbl...[color=green]
>> 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/
>>[/color]
>
>[/color]

>[color=blue][color=green]
>> You cannot catch that the power goes down is almost always my simplified
>> answer on this.[/color]
>
> That's true, but it doesn't mean that you don't need to use 'Try...Catch'
> when attempting to open a file.
>[/color]
I mean with that you cannot catch everything

Cor

"Nay Myo Aung" <noemail@noserver.com> schrieb:[color=blue]
> 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.[/color]

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

"Nay Myo Aung" wrote:
[color=blue]
> 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 :))
>[/color]

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.
[color=blue]
> 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" <MortenWennevik@hotmail.com> wrote in message
> news:opsifh60ukklbvpo@pbn_computer...[color=green]
> > 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][/color]
>
>
>
>[/color]

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]
- mvp@spam.guard.caspershouse.com

"Nay Myo Aung" <noemail@noserver.com> wrote in message
news:%230ccKST2EHA.2568@TK2MSFTNGP10.phx.gbl...[color=blue]
> 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" <ollie_riches@hotmail.com> wrote in message
> news:%23DVXcDT2EHA.2876@TK2MSFTNGP12.phx.gbl...[color=green]
>> this is just messy IMO
>>
>> Ollie
>>
>> "Rakesh Rajan" <RakeshRajan@discussions.microsoft.com> wrote in message
>> news:8DEF66C7-06FD-4564-8146-C2C9C0A188FE@microsoft.com...[color=darkred]
>>> 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[/color]
>> Catch[color=darkred]
>>> > > block to re-execute the code in Try block. If there's another[/color]
>> exception[color=darkred]
>>> > > thrown, we can evaulate that exception in one of the many Catch
>>> > > blocks[/color]
>> until[color=darkred]
>>> > > it reached to the 'unkown' exception.
>>> > >
>>> > > So, I propose that a new keyword ReTry should be incorporated in the[/color]
>> .NET[color=darkred]
>>> > > Framework 2 as an improvement.
>>> >
>>> > The first thing that catched my eye when i saw your idea is that it[/color]
>> would[color=darkred]
>>> > 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[/color]
>> of[color=darkred]
>>> > your catch block to check if this block is not being executed
>>> > endlessly.
>>> > Quite messy, isn't it?
>>> >[/color]
>>
>>[/color]
>
>[/color]

> A "small variation" is a difference. Typically you would put the code[color=blue]
> into a reusable method.[/color]

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?
[color=blue]
> I think the supposed 'ReTry' statement would make maintainance of code
> worse and make understanding and extending code harder.[/color]

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]" <hirf-spam-me-here@gmx.at> wrote in message
news:ODkFPUT2EHA.3804@TK2MSFTNGP10.phx.gbl...[color=blue]
> "Nay Myo Aung" <noemail@noserver.com> schrieb:[color=green]
>> 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[/color]
>
> 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/>[/color]

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...
[color=blue]
> \\\
> 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
> ///
>[/color]

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]" <hirf-spam-me-here@gmx.at> wrote in message
news:%23St06wT2EHA.3120@TK2MSFTNGP12.phx.gbl...[color=blue]
> "Nay Myo Aung" <noemail@noserver.com> schrieb:[color=green]
>> 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.[/color]
>
> 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/>[/color]

"Nay Myo Aung" <noemail@noserver.com> wrote[color=blue]
>
> From the following two code segments, which one do you think is more
> elegant?
>[/color]

Why only two submissions:

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

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

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

LFS

"Nay Myo Aung" wrote:
[color=blue]
> 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
>[/color]

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

> well, if such a keyword is introduced, it'd compile down to probably the[color=blue]
> 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.[/color]

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 :)
[color=blue]
> not to mention generally speaking, using exceptions to control program
> flow
> is just a very bad idea.[/color]

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" <DanielJin@discussions.microsoft.com> wrote in message
news:3440BF21-CF77-48D7-9B93-53550D5761BE@microsoft.com...[color=blue]
>
>
> "Nay Myo Aung" wrote:
>[color=green]
>> 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 :))
>>[/color]
>
> 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.
>[color=green]
>> 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" <MortenWennevik@hotmail.com> wrote in message
>> news:opsifh60ukklbvpo@pbn_computer...[color=darkred]
>> > 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][/color]
>>
>>
>>
>>[/color][/color]

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
[color=blue]
>Nay Myo Aung" <noemail@noserver.com>[/color]
[color=blue]
> 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...
>[color=green]
>> \\\
>> 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
>> ///
>>[/color]
>
> 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]" <hirf-spam-me-here@gmx.at> wrote in message
> news:%23St06wT2EHA.3120@TK2MSFTNGP12.phx.gbl...[color=green]
>> "Nay Myo Aung" <noemail@noserver.com> schrieb:[color=darkred]
>>> 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.[/color]
>>
>> 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/>[/color]
>
>[/color]

"Nay Myo Aung" <noemail@noserver.com> wrote in
[color=blue]
> For instance...[/color]

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

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

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

LFS

"Nay Myo Aung" <noemail@noserver.com> schrieb:[color=blue]
> 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?
>[color=green]
>> I think the supposed 'ReTry' statement would make maintainance of code
>> worse and make understanding and extending code harder.[/color]
>
> Could you give me an example? :)[/color]

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.
[color=blue]
> IMO, you just use one keyword "ReTry" and the corresponding Try block will
> be re-executed. Simple and clean.[/color]

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

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]" <mvp@spam.guard.caspershouse.com> wrote in
message news:uijdI7T2EHA.2192@TK2MSFTNGP14.phx.gbl...[color=blue]
> 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]
> - mvp@spam.guard.caspershouse.com
>
> "Nay Myo Aung" <noemail@noserver.com> wrote in message
> news:%230ccKST2EHA.2568@TK2MSFTNGP10.phx.gbl...[color=green]
>> 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" <ollie_riches@hotmail.com> wrote in message
>> news:%23DVXcDT2EHA.2876@TK2MSFTNGP12.phx.gbl...[color=darkred]
>>> this is just messy IMO
>>>
>>> Ollie
>>>
>>> "Rakesh Rajan" <RakeshRajan@discussions.microsoft.com> wrote in message
>>> news:8DEF66C7-06FD-4564-8146-C2C9C0A188FE@microsoft.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?
>>>> >
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

"Nay Myo Aung" <noemail@noserver.com> schrieb:[color=blue]
> '##### 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...
>[color=green]
>> \\\
>> 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
>> ///
>>[/color]
>
> 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? :)[/color]

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

"Daniel Jin" <DanielJin@discussions.microsoft.com> schrieb:[color=blue]
> 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.[/color]

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'.
[color=blue]
> not to mention generally speaking, using exceptions to control program
> flow
> is just a very bad idea.[/color]

ACK.

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

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" <notmyfirstname@planet.nl> wrote in message
news:ucKNcCU2EHA.2192@TK2MSFTNGP14.phx.gbl...[color=blue]
> 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
>[color=green]
>>Nay Myo Aung" <noemail@noserver.com>[/color]
>[color=green]
>> 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...
>>[color=darkred]
>>> \\\
>>> 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
>>> ///
>>>[/color]
>>
>> 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]" <hirf-spam-me-here@gmx.at> wrote in message
>> news:%23St06wT2EHA.3120@TK2MSFTNGP12.phx.gbl...[color=darkred]
>>> "Nay Myo Aung" <noemail@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/>[/color]
>>
>>[/color]
>
>[/color]

EXACTLY as my first post states, responsiblity, encapsualtion.....

Does this remind you of OO prinicples at all?

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:%23St06wT2EHA.3120@TK2MSFTNGP12.phx.gbl...[color=blue]
> "Nay Myo Aung" <noemail@noserver.com> schrieb:[color=green]
> > For instance, you might want to try to check which file in a list of[/color][/color]
files[color=blue][color=green]
> > (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[/color][/color]
not[color=blue][color=green]
> > as elegant as ReTry, isn't it?)...etc.[/color]
>
> 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/>
>[/color]

> That's true, but it doesn't mean that you don't need to use 'Try...Catch'[color=blue]
> when attempting to open a file.[/color]
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/

>[color=blue]
> For example, you specify another server name until a connection can be
> established. You'll have to declare 'i' outside the 'Try...Catch'.
>[/color]

When you retrieve the server names from the database, there's no need to
define i for counter.
[color=blue]
>
> To make a conclusion: I can only see minimal benefit in some simple cases
> for a 'ReTry' statement.
>[/color]

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]" <hirf-spam-me-here@gmx.at> wrote in message
news:%231z5BIU2EHA.1152@TK2MSFTNGP14.phx.gbl...[color=blue]
> "Nay Myo Aung" <noemail@noserver.com> schrieb:[color=green]
>> '##### 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...
>>[color=darkred]
>>> \\\
>>> 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
>>> ///
>>>[/color]
>>
>> 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? :)[/color]
>
> 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/>[/color]

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]" <anders.noras@objectware.no> wrote in message
news:%23eYMrLU2EHA.3128@TK2MSFTNGP14.phx.gbl...[color=blue][color=green]
> > That's true, but it doesn't mean that you don't need to use[/color][/color]
'Try...Catch'[color=blue][color=green]
> > when attempting to open a file.[/color]
> Yes, you need to catch exceptions when working with files, but you[/color]
shouldn't[color=blue]
> 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/
>
>[/color]

>>How do you change the servername with your code, the sample from Herfried[color=blue][color=green]
>>seems for me more effective for this, you only have to set the servernames
>>in an array and use a for each loop then.[/color][/color]
[color=blue]
> 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).[/color]

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

Cor

> Yes but I would careless about how it is displayed in the IL. What I would[color=blue]
> 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 :)[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
>
> --
> 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" <DanielJin@discussions.microsoft.com> wrote in message
> news:3440BF21-CF77-48D7-9B93-53550D5761BE@microsoft.com...[color=green]
> >
> >
> > "Nay Myo Aung" wrote:
> >[color=darkred]
> >> 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 :))
> >>[/color]
> >
> > 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.
> >[color=darkred]
> >> 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" <MortenWennevik@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]
> >>
> >>
> >>
> >>[/color][/color]
>
>
>[/color]

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:
[color=blue]
> Try[/color]
Retry:
[color=blue]
> '...something
>
> Catch e as FileNotFoundException
>
> 'correct the error and then[/color]
Goto Retry[color=blue]
>
> Catch e2 as DirectoryNotFoundException
>
> 'correct the error and then[/color]
Goto Retry[color=blue]
>
> Catch e3 as DriveNotFoundException
>
> 'correct the error and then[/color]
Goto Retry[color=blue]
>
> Catch '<< catch 'unknown' error
>
> 'log the error
>
> Finally
>
> End Try[/color]

"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:
[color=blue]
> Try[/color]
Retry:
[color=blue]
> '...something
>
> Catch e as FileNotFoundException
>[/color]

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

[color=blue]
> End Try[/color]

Hope this helps
Jay

"Nay Myo Aung" <owNOspaMnerATnaymyoauNOspaMng.name> wrote in message
news:uifBpxR2EHA.3452@TK2MSFTNGP14.phx.gbl...[color=blue]
> 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/
>[/color]

"Herfried K. Wagner [MVP]" wrote:
[color=blue]
> "Daniel Jin" <DanielJin@discussions.microsoft.com> schrieb:[color=green]
> > 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.[/color]
>
> 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'.
>[/color]

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.

"Daniel Jin" <DanielJin@discussions.microsoft.com> schrieb:[color=blue]
> 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.[/color]

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

"Anders Norås [MCAD]" <anders.noras@objectware.no> schrieb:[color=blue][color=green]
>> That's true, but it doesn't mean that you don't need to use 'Try...Catch'
>> when attempting to open a file.[/color]
> 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.[/color]

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

And how exactly would you implement those variations when using your
proposed ReTry statement?

Stefan

"Nay Myo Aung" <noemail@noserver.com> wrote in message
news:e2rofEU2EHA.3132@TK2MSFTNGP14.phx.gbl...[color=blue]
> 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]" <mvp@spam.guard.caspershouse.com> wrote
> in message news:uijdI7T2EHA.2192@TK2MSFTNGP14.phx.gbl...[color=green]
>> 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]
>> - mvp@spam.guard.caspershouse.com
>>
>> "Nay Myo Aung" <noemail@noserver.com> wrote in message
>> news:%230ccKST2EHA.2568@TK2MSFTNGP10.phx.gbl...[color=darkred]
>>> 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" <ollie_riches@hotmail.com> wrote in message
>>> news:%23DVXcDT2EHA.2876@TK2MSFTNGP12.phx.gbl...
>>>> this is just messy IMO
>>>>
>>>> Ollie
>>>>
>>>> "Rakesh Rajan" <RakeshRajan@discussions.microsoft.com> wrote in message
>>>> news:8DEF66C7-06FD-4564-8146-C2C9C0A188FE@microsoft.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?
>>>>> >
>>>>
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

re: Possible TRY...CATCH...END TRY

Similar .NET Framework bytes

/bytes/development

/bytes/it

/bytes/about