K
Kartic
Hi,
Is it good practice using GOTO in .NET application?
Please advice.
Thanks, Kartic
Is it good practice using GOTO in .NET application?
Please advice.
Thanks, Kartic
R
Robin Tucker
I'm not religious about it, although I don't have a single GOTO in over
50,000 lines of code in my project. It isn't neccessary. But if you feel
the need, be my guest
50,000 lines of code in my project. It isn't neccessary. But if you feel
the need, be my guest
C
Cor Ligthert
Hi Kartic,
Is this serious or do you want to build a long thread in this newsgroup.
The answer is No.
Cor
Is this serious or do you want to build a long thread in this newsgroup.
The answer is No.
Cor
W
William Ryan eMVP
Kartic:
There are a few situations where Goto may be the best solution, like in a
switch statement where you want to simulate fall-through. However, those
situations are Rare indeed and I can count them on my hand. The real
problem with Goto is that people overuse them and use them as slopppy
shortcuts. Like Robin, I think in about 60,000 lines of code, I don't think
I've ever needed to use one, and prefer not to. And my examples of
Fall-through is related to C# mainly and only deals with switch statements.
Basically, the answer is No, don't use it. If you are absolutely sure that
using GoTo is the most effecitve way to do something, then go ahead, but
limit it's use as much as possible and make sure you have a very compelling
reason to use it. And if your program uses it more than once or twice in
rare occassions, you are already overusing it.
I'm not religious about it either, I just don't see much of a need for it...
and I've seen a lot more damage done with it than good come from it.
There are a few situations where Goto may be the best solution, like in a
switch statement where you want to simulate fall-through. However, those
situations are Rare indeed and I can count them on my hand. The real
problem with Goto is that people overuse them and use them as slopppy
shortcuts. Like Robin, I think in about 60,000 lines of code, I don't think
I've ever needed to use one, and prefer not to. And my examples of
Fall-through is related to C# mainly and only deals with switch statements.
Basically, the answer is No, don't use it. If you are absolutely sure that
using GoTo is the most effecitve way to do something, then go ahead, but
limit it's use as much as possible and make sure you have a very compelling
reason to use it. And if your program uses it more than once or twice in
rare occassions, you are already overusing it.
I'm not religious about it either, I just don't see much of a need for it...
and I've seen a lot more damage done with it than good come from it.
J
Jay B. Harlow [MVP - Outlook]
Kartic,
As the others suggest, most developers feel using GOTO is not a good
practice in any language!
However! using GOTO is useful sometimes.
One place I see value is a Try/Catch block to allow retrying a statement,
something like:
Try
TRYAGAIN:
AttemptToReadFile()
' Throw New System.IO.FileNotFoundException
Catch ex As System.IO.FileNotFoundException
If MessageBox.Show("What would you like to do?", "File not
found", MessageBoxButtons.RetryCancel, MessageBoxIcon.Question,
MessageBoxDefaultButton.Button2) = DialogResult.Retry Then
GoTo TRYAGAIN
Else
Throw ' let error propagate up
End If
End Try
Where the AttemptToReadFile method opens a file and attempts to read it, if
the file is not found, a dialog is shown to the user, and the Goto allows
the program to try the AttemptToReadFile a second time. I would only handle
specific exceptions this way, for example FileNotFoundException instead of
System.Exception.
Another place I see value is in complicated loops, within loops, when you
need to get out of an inner most loop, back to the outer most loop quickly,
however I attempt to avoid nesting loops (directly) too much...
Hope this helps
Jay
As the others suggest, most developers feel using GOTO is not a good
practice in any language!
However! using GOTO is useful sometimes.
One place I see value is a Try/Catch block to allow retrying a statement,
something like:
Try
TRYAGAIN:
AttemptToReadFile()
' Throw New System.IO.FileNotFoundException
Catch ex As System.IO.FileNotFoundException
If MessageBox.Show("What would you like to do?", "File not
found", MessageBoxButtons.RetryCancel, MessageBoxIcon.Question,
MessageBoxDefaultButton.Button2) = DialogResult.Retry Then
GoTo TRYAGAIN
Else
Throw ' let error propagate up
End If
End Try
Where the AttemptToReadFile method opens a file and attempts to read it, if
the file is not found, a dialog is shown to the user, and the Goto allows
the program to try the AttemptToReadFile a second time. I would only handle
specific exceptions this way, for example FileNotFoundException instead of
System.Exception.
Another place I see value is in complicated loops, within loops, when you
need to get out of an inner most loop, back to the outer most loop quickly,
however I attempt to avoid nesting loops (directly) too much...
Hope this helps
Jay
R
Robin Tucker
Yes, the second example is one I've come across a lot in my code. Instead
of using the GOTO, I tend to use a boolean flag to tell me when to break out
of the loop. Actually, in this case, I would hardly say it was easier to
read or understand the flow of code, but I've just become used to doing
things like this rather than using gotos'.
of using the GOTO, I tend to use a boolean flag to tell me when to break out
of the loop. Actually, in this case, I would hardly say it was easier to
read or understand the flow of code, but I've just become used to doing
things like this rather than using gotos'.
C
Cor Ligthert
Hi Jay B. (And Bill)
I never come with documents, however this greath Dutchman will turn around
about your writting.
(He has done very much for modern programming, in my idea most modern
languages derives partialy from his ideas)
http://www.cs.utexas.edu/users/EWD/
http://www.acm.org/classics/oct95/
Cor
I never come with documents, however this greath Dutchman will turn around
about your writting.
(He has done very much for modern programming, in my idea most modern
languages derives partialy from his ideas)
http://www.cs.utexas.edu/users/EWD/
http://www.acm.org/classics/oct95/
Cor
J
Jay B. Harlow [MVP - Outlook]
Robin,
Agreed.
I would consider the Boolean over the Goto, until the Boolean was
complicating & convoluting the code too much... In that there is stuff after
the inner loops that need to be skipped, so you have to include the Boolean
on each loop, then you need if statements that check the Boolean, then you
need...
Remember bad use of a Goto does not make the Goto bad!
Too many developers think Goto is Bad! as they have seen bad uses of Goto
too often...
Jay
Agreed.
I would consider the Boolean over the Goto, until the Boolean was
complicating & convoluting the code too much... In that there is stuff after
the inner loops that need to be skipped, so you have to include the Boolean
on each loop, then you need if statements that check the Boolean, then you
need...
Remember bad use of a Goto does not make the Goto bad!
Too many developers think Goto is Bad! as they have seen bad uses of Goto
too often...
Jay
J
Jay B. Harlow [MVP - Outlook]
Cor,
First a question: Why are you attempting to build a long thread? ;-)
As I told Robin:
Remember bad use of a Goto does not make the Goto bad!
Too many developers think Goto is Bad! as they have seen bad uses of Goto
too often...
The second link is interesting, I don't see what you are trying to say with
the first (other then who wrote the second).
Just a thought
Jay
First a question: Why are you attempting to build a long thread? ;-)
As I told Robin:
Remember bad use of a Goto does not make the Goto bad!
Too many developers think Goto is Bad! as they have seen bad uses of Goto
too often...
The second link is interesting, I don't see what you are trying to say with
the first (other then who wrote the second).
Just a thought
Jay
C
CJ Taylor
Jay B. Harlow said:
It's been awhile... =)
R
Robin Tucker
I think though, if I remember my formal specification classes, that using
GOTOs does tend to mess up any mathematical description of your process (not
that we tend to design our applications in "Z" before implementing them in
VB!).
GOTOs does tend to mess up any mathematical description of your process (not
that we tend to design our applications in "Z" before implementing them in
VB!).
C
Cor Ligthert
Hi Jay,
Because I always know this hits me, I have seen so often bad programs which
with thinking how to provide the "goto" became suddenly much better (not a
religion, a trick to make better programs).
The Goto has after somewhere 1970 always been for me a bad command (In the
begin it was nothing more than a branch unconditional)
programmers more easy to understand I think.
The first was to show who wrote it, not a simple Dutchman, which you may
think when you see the second link.
Cor
Because I always know this hits me, I have seen so often bad programs which
with thinking how to provide the "goto" became suddenly much better (not a
religion, a trick to make better programs).
The Goto has after somewhere 1970 always been for me a bad command (In the
begin it was nothing more than a branch unconditional)
In my idea still Goto's in scripting languages, it is for not good
programmers more easy to understand I think.
The first was to show who wrote it, not a simple Dutchman, which you may
think when you see the second link.
Cor
H
Herfried K. Wagner [MVP]
* "Cor Ligthert said:
Dijkstra formulared the "Dining Philosophers' Problem", didn't he ;-).
J
Jay B. Harlow [MVP - Outlook]
Herfried,
wrote someplace...
I believe you are correct, I don't have my reference handy...
Jay
I like the "Dining Philosophers' Problem", I have a VB.NET implementation I
wrote someplace...
I believe you are correct, I don't have my reference handy...
Jay