Groups | Blog | Home
all groups > dotnet academic > december 2004 >

dotnet academic : Possible TRY...CATCH...END TRY


Rakesh Rajan
12/3/2004 2:35:04 AM
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

[quoted text, click to view]
Rakesh Rajan
12/3/2004 2:55:02 AM
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

[quoted text, click to view]
Daniel Jin
12/3/2004 5:45:01 AM


[quoted text, click to view]

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.

[quoted text, click to view]
Daniel Jin
12/3/2004 5:55:02 AM
[quoted text, click to view]

you are already violating what not to do with exceptions when you write code
Daniel Jin
12/3/2004 6:35:11 AM
[quoted text, click to view]

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.

[quoted text, click to view]

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.

[quoted text, click to view]
Daniel Jin
12/3/2004 6:43:02 AM
[quoted text, click to view]

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
Larry Serflaten
12/3/2004 7:55:50 AM

[quoted text, click to view]

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
Larry Serflaten
12/3/2004 8:04:04 AM

"Nay Myo Aung" <noemail@noserver.com> wrote in

[quoted text, click to view]

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

Jay B. Harlow [MVP - Outlook]
12/3/2004 8:38:37 AM
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:

[quoted text, click to view]
Retry:

[quoted text, click to view]

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

[quoted text, click to view]
Retry:

[quoted text, click to view]

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


[quoted text, click to view]

Hope this helps
Jay

[quoted text, click to view]

Nicholas Paldino [.NET/C# MVP]
12/3/2004 8:47:45 AM
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

[quoted text, click to view]

Elp
12/3/2004 10:10:38 AM
[quoted text, click to view]

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.
Anders Norås [MCAD]
12/3/2004 11:40:12 AM
[quoted text, click to view]

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

David
12/3/2004 11:54:41 AM
[quoted text, click to view]

Neither. They're both extremely ugly. The problem is that you're using
try/catch for a ordinary loop.


[quoted text, click to view]

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.

Morten Wennevik
12/3/2004 12:00:26 PM
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!
Cor Ligthert
12/3/2004 12:02:59 PM
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>

[quoted text, click to view]

Ollie
12/3/2004 12:08:51 PM
this is just messy IMO

Ollie

[quoted text, click to view]

Darren Barrick
12/3/2004 12:37:33 PM
Look at the Eiffel Language :)

[quoted text, click to view]

Mattias Sjögren
12/3/2004 1:33:25 PM

[quoted text, click to view]


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
Mattias Sjögren
12/3/2004 1:35:28 PM
Anders,

[quoted text, click to view]

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
Herfried K. Wagner [MVP]
12/3/2004 1:38:57 PM
"Nay Myo Aung" <noemail@noserver.com> schrieb:
[quoted text, click to view]

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/>
Herfried K. Wagner [MVP]
12/3/2004 1:40:30 PM
"Nay Myo Aung" <noemail@noserver.com> schrieb:
[quoted text, click to view]

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/>
Cor Ligthert
12/3/2004 1:43:22 PM
Mattias,

[quoted text, click to view]

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

Is up to you if you agree that with me

:-)

Cor

Herfried K. Wagner [MVP]
12/3/2004 1:46:25 PM
"Cor Ligthert" <notmyfirstname@planet.nl> schrieb:
[quoted text, click to view]

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/>
Ollie
12/3/2004 2:18:04 PM
EXACTLY as my first post states, responsiblity, encapsualtion.....

Does this remind you of OO prinicples at all?


[quoted text, click to view]

Cor Ligthert
12/3/2004 2:24:24 PM
[quoted text, click to view]
I mean with that you cannot catch everything

Cor

Herfried K. Wagner [MVP]
12/3/2004 2:30:17 PM
"Nay Myo Aung" <noemail@noserver.com> schrieb:
[quoted text, click to view]

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/>
Ollie
12/3/2004 2:31:28 PM
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


[quoted text, click to view]

Cor Ligthert
12/3/2004 3:03:13 PM
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

[quoted text, click to view]

Herfried K. Wagner [MVP]
12/3/2004 3:03:39 PM

"Nay Myo Aung" <noemail@noserver.com> schrieb:
[quoted text, click to view]

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.

[quoted text, click to view]

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/>
Herfried K. Wagner [MVP]
12/3/2004 3:11:38 PM
"Nay Myo Aung" <noemail@noserver.com> schrieb:
[quoted text, click to view]

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/>
Herfried K. Wagner [MVP]
12/3/2004 3:13:22 PM
"Daniel Jin" <DanielJin@discussions.microsoft.com> schrieb:
[quoted text, click to view]

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

[quoted text, click to view]

ACK.

--
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]
12/3/2004 3:17:07 PM
[quoted text, click to view]
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/

Cor Ligthert
12/3/2004 3:36:38 PM
[quoted text, click to view]


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

Cor

Herfried K. Wagner [MVP]
12/3/2004 3:47:10 PM
"Daniel Jin" <DanielJin@discussions.microsoft.com> schrieb:
[quoted text, click to view]

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/>
Herfried K. Wagner [MVP]
12/3/2004 3:51:30 PM
"Anders Norås [MCAD]" <anders.noras@objectware.no> schrieb:
[quoted text, click to view]

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/>
Stefan Simek
12/3/2004 4:32:56 PM
And how exactly would you implement those variations when using your
proposed ReTry statement?

Stefan

[quoted text, click to view]

Herfried K. Wagner [MVP]
12/3/2004 9:31:47 PM
"Nay Myo Aung" <noemail@noserver.com> schrieb:
[quoted text, click to view]

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

Larry Serflaten
12/3/2004 10:25:52 PM

[quoted text, click to view]

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.

Nay Myo Aung
12/3/2004 10:36:16 PM
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/

David Pope
12/3/2004 10:54:01 PM
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


[quoted text, click to view]

Robby
12/3/2004 11:00:28 PM

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


[quoted text, click to view]

Nay Myo Aung
12/4/2004 1:24:29 AM
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/


[quoted text, click to view]

Nay Myo Aung
12/4/2004 1:25:27 AM
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/

[quoted text, click to view]

Nay Myo Aung
12/4/2004 1:25:33 AM
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/

[quoted text, click to view]


Nay Myo Aung
12/4/2004 1:25:44 AM
Hi Morten,

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

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

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

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

Dim intCurFileTryArray as Integer

Try

SomethingToDoWithFile(strArrayFileTryList(intCurFileTryArray))

Catch e as Exception1

intCurFileTryArray += 1

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

Catch

End Try

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

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

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

Dim intCurFileTryArray as Integer

ReStart:

Try

SomethingToDoWithFile(strArrayFileTryList(intCurFileTryArray))

Catch e as Exception1

intCurFileTryArray += 1

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

Catch

End Try

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

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

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

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


[quoted text, click to view]


Nay Myo Aung
12/4/2004 1:35:02 AM
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/

[quoted text, click to view]

Nay Myo Aung
12/4/2004 2:16:34 AM
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/


[quoted text, click to view]

Nay Myo Aung
12/4/2004 2:19:18 AM
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/technologies/dotnet/eiffel_dotnet_language/20_language/60_exception_mechanism.html

Thanks for pointing me out!!

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

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

[quoted text, click to view]