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/ 48  1206 
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/
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?
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?
> 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
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
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> 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 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?
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/
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/
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?
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] 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.
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.
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?
>
"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/>
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/
"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/>
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
> 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/>
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/
>>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
> 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]
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/
"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.
"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/>
"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/>
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?
> >
On 2004-12-03, Nay Myo Aung <no*****@noserver.com> 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 :))
From the following two code segments, which one do you think is more
elegant?
Neither. They're both extremely ugly. The problem is that you're using
try/catch for a ordinary loop.
******* 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 ***********
All you're doing here is attempting an action on each available file,
and continuing on first success. This is a pretty common task...
For Each currentName in strArrayTryList
if SomethingToDoWithFile(filename)
return filename
End If
Next
MessageBox.Show("cannot open any file")
**********
If there must be a try/catch to handle a simple boolean operation, then
that should be encapsulated in the SomethingToDoWithFile function.
There's no need for retry here, and a Retry would make a very simple
operation much harder to read.
As somebody else mentioned, exceptions should be exceptional. They
shouldn't be used as looping constructs. And I see little use of a new
keyword that is designed to enable bad code.
"Nay Myo Aung" <no*****@noserver.com> schrieb: 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.
On the one hand you are talking about 2-liners that don't need to be added
to a separate method because of the calling overhead (which is not
necessarily the case because the JITter can do inlining of small methods),
on the other hand, you are talking about "small variations" (inside these
two lines?!). If there is little redundancy I don't see a way of
implementing that with both, a 'ReTry' statement and by placing the code in
a method. Nested 'Try...Catch' blocks are the way to go.
--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
We VB programmers have been using On Error Goto <label> to fix errors and
rerun blocks of code for years with out trapping ourselves in endless loops.
Are you telling me that the MFC C++ programmers are not capable of doing
this.
Robby
"Elp" <ro********@REMOVEME.hotmail.com> wrote in message
news:10******************************@40tude.net.. . 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?
> However this is not the answer on your question accoording to your pevious sample.
What do you mean?
--
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:OA****************@TK2MSFTNGP10.phx.gbl... 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
> If there is little redundancy I don't see a way of implementing that with both, a 'ReTry' statement and by placing the code in a method. Nested
'Try...Catch' blocks are the way to go.
Espeically when you are during the development phase (the time that you make
changes to the code and debug again and again), having about three or four
nested Try block to do the same thing, it just annoying to change all these
code blocks (which must have the same logic). While debugging, forgetting to
change the code on one of the Try blocks results in unexpected and
unpredictable program behaviour and makes the debugging process more time
consuming than it should.
So yea, we could put that code in a method instead. It solves the problem
for the programmers with the cost of system resources. Imagine you have to
put every 3 or 4 lines of code to a sub that is to be used in Try...Catch
blocks, I think it just a waste of sys resources, plus more code (having to
write many Sub procedure declarations and more indented Try...Block code,
just to do some simple Try...ReTry logic).
--
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:e8*************@TK2MSFTNGP09.phx.gbl... "Nay Myo Aung" <no*****@noserver.com> schrieb: 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.
On the one hand you are talking about 2-liners that don't need to be added
to a separate method because of the calling overhead (which is not
necessarily the case because the JITter can do inlining of small methods),
on the other hand, you are talking about "small variations" (inside these
two lines?!). If there is little redundancy I don't see a way of
implementing that with both, a 'ReTry' statement and by placing the code
in a method. Nested 'Try...Catch' blocks are the way to go.
--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Hi Stefan,
I just copied and pasted from my other post...
'##### 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 #####
You could use For...Next loop for this piece of logic (and still need the
Try...Catch block in addition to that). What I have here is a logical
grouping of "performing" code, "error handling/retry" code and "clean up"
code, all in one for a task.
Furthremore, with For...Next loop, you have to write clean up code **after**
the loop exit. With my proposed method, you got a logical
grouping/integration of clean up code in the "Finally" block.
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/
"Stefan Simek" <si********@kascomp.blah.sk> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl... 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?
>> >
>
>
Hi Robby,
I don't know about MFC C++ programmers. But Effiel for .NET has implemented
what I'm currently proposing.
See: http://docs.eiffel.com/eiffelstudio/...mechanism.html
--
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:uT**************@TK2MSFTNGP09.phx.gbl...
We VB programmers have been using On Error Goto <label> to fix errors and
rerun blocks of code for years with out trapping ourselves in endless
loops. Are you telling me that the MFC C++ programmers are not capable of
doing this.
Robby
"Elp" <ro********@REMOVEME.hotmail.com> wrote in message
news:10******************************@40tude.net.. . 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?
Hi Jay,
Thanks, I will try input my 2 cents there.
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/
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:uj**************@TK2MSFTNGP15.phx.gbl... 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/
> 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.
There aren't more complex "ReTry" uses, ReTry will just retry the
corresponding Try block. Nothing beyond that. And it will stop retrying
after a certain codition is met. If it is much more complex than that, we
might not use ReTry, we might use something else.
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.
Look at this way, if we want to loop through something (such as looping
through a collection and add ListItems to a ListBox as we loop) certainly we
will use For...Next loop. But for ***ReTrying*** a task that appear in the
Try block after an exception is thrown, it doesn't make sense to use
For...Next loop but make sense to use ReTry statement. You can also put the
"final code" (such as display an error message that it cannot be retried
anymore) in the Finally block which I think totoally make sense. You cannot
utilize Finally block if you were in the For...Next loop.
So no, I don't think I'm proposing Try...ReTry as a "loop back" like
For...Next. I'm just proposing to enhance the error handling construct.
My 2 cents also...
--
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:eH*************@TK2MSFTNGP12.phx.gbl...
"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/>
Hi Larry, what makes you think
a 'small variation' would work?
I just copied and pasted from my other post...
'##### 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 #####
In this case, a small variation is the Server Name.
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/
"Larry Serflaten" <se*******@usinternet.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
"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
"Nay Myo Aung" <no*****@noserver.com> schrieb: I don't know about MFC C++ programmers. But Effiel for .NET has
implemented what I'm currently proposing.
See:
http://docs.eiffel.com/eiffelstudio/...mechanism.html
Quoted from the referenced document:
| It should be noted that rescue 'clauses' and 'retry' instructions
| are not something that are used commonly. Out of the
| approximately 2000 class in the delivered Eiffel libraries,
| there are only 16 occurrences. Many of these are oriented
| toward network and database operations for which some
| reasonable recovery might be possible.
If something is not used "commonly", the programming language should IMHO
not provide special commands for it, at least not VB.
--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/> If something is not used "commonly",
Not commonly in the 2000 classes of Effiel language. However, it certainly
common and comes handy in most of the everyday business software development
projects (at least those I've undertaken).
at least not VB.
Well, shouldn't all dot net langauges provide the same power and features
regardless? :) One shouldn't need to say "I must use this language to do
that" in the .NET world? This is the philosophy of .NET Framework, isn't 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/
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:e2*************@TK2MSFTNGP11.phx.gbl... "Nay Myo Aung" <no*****@noserver.com> schrieb: I don't know about MFC C++ programmers. But Effiel for .NET has
implemented what I'm currently proposing.
See:
http://docs.eiffel.com/eiffelstudio/...mechanism.html
Quoted from the referenced document:
| It should be noted that rescue 'clauses' and 'retry' instructions
| are not something that are used commonly. Out of the
| approximately 2000 class in the delivered Eiffel libraries,
| there are only 16 occurrences. Many of these are oriented
| toward network and database operations for which some
| reasonable recovery might be possible.
If something is not used "commonly", the programming language should IMHO
not provide special commands for it, at least not VB.
--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
"Nay Myo Aung" <no*****@noserver.com> wrote Well, shouldn't all dot net langauges provide the same power and features
regardless? :) One shouldn't need to say "I must use this language to do
that" in the .NET world? This is the philosophy of .NET Framework, isn't it?
That was not the philosophy as I understood it. What I heard was that the
langugaes we going to be allowed to diverge so that each can do what is best
for their own target developers. For example, you won't see the unmanaged
power of C++ in managed VB, yet they both are available in Visual Studio .Net.
LFS
I think this thread is example of what could happen if Microsoft implements
the Retry.
An endless thread loop. =0}
Have a great weekend everyone!
David
"Nay Myo Aung" <no*****@noserver.com> wrote in message
news:ON*************@TK2MSFTNGP11.phx.gbl... Hi Jay,
Thanks, I will try input my 2 cents there.
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/
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:uj**************@TK2MSFTNGP15.phx.gbl... 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/
Hi David,
Good sense of humor there :)
Seriously, it rather seem as a myth that using ReTry could result in an
endless loop. Usually, it will **not** result in the endless loop. Consider
the following example...
'#### Code ####
Dim strFileName as String
Try
'>> Open a File
OpenFile(strFileName)
Catch
' On error...
'Ask user to input the file name, such as using common dialog...
If objDlg.Show() <> vbCancel Then
strFileName = objDlg.FileName
ReTry
End If
Finally
' Clean up code
End Try
'#### End Code ####
In above example code, it tries to open a file. If there's an error (such as
file not found) the user is asked to input the file name (such as using a
Common Dialog). After entering the file name it will retry. If user click
"cancel" in the Common Dialog, it will exit. Now, where's the endless loop?
:)
It will be looping endlessly only if the user endlessly specifying the wrong
file. It's not the fault of the program. It's the fault of the user. The
user have the option to select "Cancel" if he/she want to break the loop.
The program will only loop because the user wants it to loop.
It is usually common for the need to manage file-open, file-save routines in
GUI based applications. This is one of the areas where ReTry will largely
benefit IMO.
You also have a great weekend 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/
"David Pope" <dp***@nospam.satx.rr.com> wrote in message
news:eg**************@TK2MSFTNGP14.phx.gbl... I think this thread is example of what could happen if Microsoft implements
the Retry.
An endless thread loop. =0}
Have a great weekend everyone!
David
"Nay Myo Aung" <no*****@noserver.com> wrote in message
news:ON*************@TK2MSFTNGP11.phx.gbl... Hi Jay,
Thanks, I will try input my 2 cents there.
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/
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:uj**************@TK2MSFTNGP15.phx.gbl... 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/
You should try Eiffel!
In Eiffel, the exception is rethrown automatically if you don't do anything
special in your catch clause and the only way to prevent the exception from
being rethrown is to do a RETRY! So, this concept exists in other languages.
Bruno.
"Nay Myo Aung" <owNOspaMnerATnaymyoauNOspaMng.name> a écrit dans le message
de 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/
"Mattias Sjögren" <ma********************@mvps.org> a écrit dans le message
de news: %2****************@TK2MSFTNGP10.phx.gbl... 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.
I don't agree, and I know about the atomicity problem (the fact that the
file may disappear between your Exists test and the open call).
My guidelines are the following:
1) You MUST use a try/finally (or better a "using" block) to guarantee that
the file will be closed in a predictable way.
2) In normal circumstances (99.99% of the time), you should NOT introduce
any catch clause around file open logic, you should let exceptions percolate
to a generic catchall that reports and logs all exceptions.
3) There are situations where you should test with Exists before opening and
there are other situations where you should NOT test with Exists.
4) There are some VERY RARE situations where you need both the Exists test
and a try/catch, but normally you don't.
Some words of explanation:
1) I am sure that everybody will agree about this one.
2, 3, and 4). It all boils down to how you draw the line between a "normal"
context of execution and an "abnormal" one.
Here are some assumptions that I consider to be true in a "normal" context
of execution:
a) The vital files that my installer has placed in the Program Files area
have not been deleted by the user. If they have, the user will have to fix
it by restauring the file or reinstalling the application.
b) There is no "sweeper" program that runs in the background and deletes
files in an unpredictable way. So, if my application creates a file and then
tries to open it a few seconds later, the file should still be there. If
there is such a sweeper program then the user should identify the culprit
(virus?) and put his system back into a stable mode.
c) The application may use some optional files. In this case, the
application will have to test if the file exists or not before opening it,
and the application will have a fallback strategy (like using some default
values instead of values read from the file).
d) There may be special situations where the application will use files to
exchange data with another application. If the synchronization protocol
between the two apps is weak, the application must be ready to handle the
case where the file gets deleted by the other app in unpredictable ways (for
example between a call to Exists and a call to open).
So, here are the coding patterns that I recommend in some common scenarios:
When the application needs to open a "vital" file created by the installer,
or a temp file that another method has created just before (cases a and b),
the correct pattern is:
using (Stream stream = File.Open(filename, ...)) {
DoSomething(stream); }
When the application need to work with an "optional" file (case c), the
correct pattern is:
if (File.Exists(filename))
using (Stream stream = File.Open(finename, ...)) {
DoSomething(stream); }
else
UseDefaultValues();
In the very special situation described in d) above (and I would not
recommend using this kind of interprocess communication but sometimes this
is the only way to deal with legacy apps), The correct pattern is:
using (Stream stream = MyFileHelper.TryOpen(filename, ...))
{
if (stream != null)
DoSomething(stream);
}
where MyFileHelper.TryOpen is coded as:
Stream TryOpen(filename, ...)
{
if (!File.Exists(string filename))
return null;
try {
return File.Open(filename, ...);
}
catch (FileNotFoundException ex)
{
return null;
}
}
With these guidelines, you get simple, understandable application code
(instead of a big mess of try/catch), and you know exactly the assumptions
that the developer makes about the files (is it a file that should always
exist? and if it does not, this is just as abnormal as if the disk was bad,
or is it an optional file? or is it a file that may disappear in
unpredictable ways?).
In short, the pattern that you will be using depends on the assumptions that
you make about your operating environment. In many cases, the simplest
pattern (just opening the file without any Exists test nor any catch clause)
is the one to use.
Bruno.
Mattias
--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
"Nay Myo Aung" <no*****@noserver.com> schrieb: If something is not used "commonly",
Not commonly in the 2000 classes of Effiel language. However, it certainly
common and comes handy in most of the everyday business software
development projects (at least those I've undertaken).
It seems that you are the only one who is missing 'ReTry' ;-)))... at least not VB.
Well, shouldn't all dot net langauges provide the same power and features
regardless? :) One shouldn't need to say "I must use this language to do
that" in the .NET world? This is the philosophy of .NET Framework, isn't
it?
The main goal of .NET was language interoperability based on the CLS, not
providing the same language features in all .NET programming languages.
--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nay,
I was playing. I think a Try...Retry(<number of retries>) would work.
I like it.
It would be very useful.
Thanks,
David
"Nay Myo Aung" <no*****@noserver.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... Hi David,
Good sense of humor there :)
Seriously, it rather seem as a myth that using ReTry could result in an
endless loop. Usually, it will **not** result in the endless loop.
Consider the following example...
'#### Code ####
Dim strFileName as String
Try
'>> Open a File
OpenFile(strFileName)
Catch
' On error...
'Ask user to input the file name, such as using common dialog...
If objDlg.Show() <> vbCancel Then
strFileName = objDlg.FileName
ReTry
End If
Finally
' Clean up code
End Try
'#### End Code ####
In above example code, it tries to open a file. If there's an error (such
as file not found) the user is asked to input the file name (such as using
a Common Dialog). After entering the file name it will retry. If user
click "cancel" in the Common Dialog, it will exit. Now, where's the
endless loop? :)
It will be looping endlessly only if the user endlessly specifying the
wrong file. It's not the fault of the program. It's the fault of the user.
The user have the option to select "Cancel" if he/she want to break the
loop. The program will only loop because the user wants it to loop.
It is usually common for the need to manage file-open, file-save routines
in GUI based applications. This is one of the areas where ReTry will
largely benefit IMO.
You also have a great weekend 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/
"David Pope" <dp***@nospam.satx.rr.com> wrote in message
news:eg**************@TK2MSFTNGP14.phx.gbl...I think this thread is example of what could happen if Microsoft
implements the Retry.
An endless thread loop. =0}
Have a great weekend everyone!
David
"Nay Myo Aung" <no*****@noserver.com> wrote in message
news:ON*************@TK2MSFTNGP11.phx.gbl... Hi Jay,
Thanks, I will try input my 2 cents there.
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/
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in
message news:uj**************@TK2MSFTNGP15.phx.gbl...
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/
>
"Nay Myo Aung" wrote: 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/
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| |
