The story on goto 1

[MrMoocow]

Okay,
I'm doing a sorta "poll". Even though I'm "know my way around VB" I took a VB course in order to be able to take a C++ class. My instructor insist that goto's are improper in any case. On the subject of Error handling it says you shouldn't have errors. So I would like some replys saying wether or not you use goto.

Thanks. Brad,
Hey! email me any time! Bradsvb@yahoo.com

 

[Jon4747]

Hi Brad,

I was taught that proper testing would eliminate all possible errors and, therefore, any need for errorhandling.
That being said, ask your instructor how would you deal with the cancel button on a common dialog box without errorhandling and the goto keyword.

Jon

 

[strongm]

The native error handling in current versions of VB is inelegant and inefficient (and a legacy of VB's history); as such it forces you to use GOTO. The fact that GOTO is considered by some purists as being a no-no should in no way stop you writing error handling code. By the way, it's fixed in VB.NET

As for whether or not I use GOTO or not beyond error handling, the answer is that I tend not to - but that's more because the language is rich enough in features not to actually need it, rather than because I think it is intrinsically wrong.

 

[petermeachem]

Funny how non-real world some teachers can be. No errors eh. I suppose given enough time and hence money, we could produce error free code. This would imply the MS operating system and the computer hardware and the telephone system/cable etc etc and everything else all being perfect too. I don't think anything would get done. And no-one would pay that much.

I only use goto for on error code. Quite acceptable. I would use it to get out a loop or an if or something if it produced neater code, but it hasn't so far. Peter Meachem
peter@accuflight.com

 

[AdaHacker]

It's an old prejudice that GOTOs are bad. It started with Djikstra's legendary letter "GOTOs considered harmful" which you can read in the ACM archive at

http://www.acm.org/classics/oct95/

Basically, the idea is that GOTOs as they were used at the time often created "spaghetti code," i.e. code that you couldn't really follow. Control just jumped willy-nilly all over the place, going from one context to a radically different one. Obviously, such use made the code a nightmare to maintain. On top of that, a GOTO is really nothing but an unconditional jump, wich is a very low level construct to be used as part of a high level language. It kind of defeats the purpose.

Of course, if used properly, there's nothing wrong with GOTOs. (Even the guide to bad code tells us that. See

http://www.exmsft.com/~hanss/badcode.htm

)
They're usually not the best way to handle something, even error detection, but in some cases, you don't have a choice. In other cases, an alternative construct might just be too cumbersome. In other words, don't avoid the GOTO just because it's a GOTO. But, on the other hand, don't abuse it just because it's quick and easy.

 

[MikeCox]

I've used goto outside of error handling a few times, mostly to skip to the cleanup part of a procedure early on. But I admit that with a little more effort it could've been avoided. I think it's gotten a lot of bad rap because it leads to the kind of spagetti program flow that'll give you debugging nightmares for weeks. Phasing out the procedural paradigm in favor of OOP also requires discouraging its use, but aside from these two (legitimate) arguments, I think that its use is perfectly acceptable in those isolated cases where it makes more sense than calling a function.

~Mike
Any man willing to sacrifice liberty for security deserves neither liberty nor security.

-Ben Franklin

 

[JohnYingling]

Here is how I like to use error handling with
no GOTO

Dim strWhile as string
Do  ' Code Block DO
    strWhile = "Opening File=" & strFilename
    On error Resume next
        Open strFileName.....
        strResponse = Err.Description
    On error goto 0
    if Len(strResponse) > 0 then exit do
    Do While not (..)
        strWhile = "Reading File=" & strFileName
        On error Resume next 
            ....read
            strResponse = Err.Description
        on error goto 0  
        if Len(strResponse) > 0 then exit do 
        on error resume next
            .... call processRecord 
            strResoonse = Err.Description
        On error goto 0
        if Len(strResponse) > 0 then eit do     
     Loop
     Exit DO
Loop
On Error Resume next
    close ....
On error GOTO 0 
if Len(strResponse) > 0 then
    strResponse = strResponse & vbcrlf & strWhile
    MsgBox strResponse 
    ...OR
    Err.Raise vbobjectERRor + 513, "Module", strResponse
End if

http://www.VBCompare.com

Compare Code (Text)

http://www.VBSortGen.com

Generate Sort in VB or VBScript

 

[petermeachem]

Which I reckon proves the point. Around half your code is nothing to do with the programme, but only to do with avoiding typing on error goto errorcode at the start. Which all makes it harder to debug.
Or am I mistaken. (got to be careful, go told off for being rude!) Peter Meachem
peter@accuflight.com

 

[petermeachem]

Which I reckon proves the point. Around half your code is nothing to do with the programme, but only to do with avoiding typing on error goto errorcode at the start. Which all makes it harder to debug.
Or am I mistaken. (got to be careful, got told off for being rude!) Peter Meachem
peter@accuflight.com

 

[WilMead]

You have to look beyond the letters G, O, T, O to get to the real intent of our GOTO-IS-BAD revolution. Once you appreciate our goal, you can easily see that judicious use of GOTO is necessary, in some languages.

Try writing a process in the CMD or Batch language for instance. The Logical (IF) construct doens't come with the familiar else and then. You are forced to code with GOTO. Even so, by embracing our revolution's cause you can create very nice code.

[tt]
IF -TEST- THEN GOTO ThenLabel
ELSE processing
GOTO EndLabel
:ThenLabel
THEN processing
:EndLabel
[/tt]

I used a macro that replaced "Label" with a 4 digit number allowing me to design some pretty nasty nested logic. See why I think of If-Else-Thens, and not If-Then-Elses.

Look at the new words that evolved from our revolt. Exit Do(break for the C programmers), and Continue. Aren't these just specialized gotos?

As a matter of fact, I'll use
[tt]
do
...
exit do
Loop
[/tt]
just to avoid using the four lettered taboo.

From the sounds of it, your instructor has lost sight of our goal. It's not GOTO that's bad, it's the mess generated by allowing it's unrestricted use that is.



Wil Mead
wmead@optonline.net

 

[JohnYingling]

The "Try, Catch, Finaly" model of exception handling is coming in VB.NET so get used to "bracketing" code with exception handling. On Error will still be supported for compatibility... and diehards.

http://www.VBCompare.com

Compare Code (Text)

http://www.VBSortGen.com

Generate Sort in VB or VBScript

 

[WilMead]

More specialized goto's hidden in macros.

Wil Mead
wmead@optonline.net

 

[MikeCox]

Another error handling method that avoids goto:

On Error Resume Next
...
...
Select Case Err.Number
Case 0
'no error occured

Case Else
MsgBox Err.Description
Err.Clear

End Select

On Error Goto 0

The Try/Catch feature is nice, thanks for the good news John.

Any man willing to sacrifice liberty for security deserves neither liberty nor security.

-Ben Franklin

 

[petermeachem]

I first came across this arguement years ago when I was writing software for flight simulators in Fortran. We started off in Fortran 4 I suppose it was which had no if then else. We then had a preprocessor which did so we could use nice vb like code and then Fortran 77 (I think) which had if then else built it. Not having if then else meant absolutely awful code that was so hard to debug. When we had if then else, we also developed a strange sort of religious fervour. Using a goto was somehow wicked and people used all sorts of complicated schemes to avoid them. Using labels also messed up the compiler optimisation. It optimised in blocks and started again when it found a label.
Here endeth the lesson.
PS. If you think goto's make your code messy, try writing in machine code.
Peter Meachem
peter@accuflight.com

 

[cdukes]

As far as I am concerned, GOTO not only creates "spaghetti code" but also can creates serious programming errors and bugs that are impossible to find. This is not so much the case with VB as you are protected to some extent, but can be much more serious in a language like c or c++ where you are passing around pointers to memory and objects.

When you are passing around pointers and Pointers to pointers etc, you have no knowledge of whether you are pointing to a valid area of memory or not. All you can rely on is whether it is NULL or not. When using GOTO's in such languages, jumping out of code can inevitable leave pointers around with valid values, even though the memory has long since gone. If you try to access the memory at the said address, BIG BANG and GPF.

Chris Dukes

 

[JohnYingling]

I use DO / Exit DO: Loop as a code container for "jumping" out of code.

Do
    ....
    if ng then exit do ' GOTO end of block
    ...
Exit Do: Loop
' Simulate CONTINUE inside For (or Do)
For I = 0 .....
    blnContinue = false
    Do      ' Block begin
        ....
        if blnContinue then exit do ' continue outer Loop
        .....
    Exit Do: Loop ' Block End
Next

http://www.VBCompare.com

Compare Code (Text)

http://www.VBSortGen.com

Generate Sort in VB or VBScript

 

[MrMoocow]

Thanks. So I will continue to use error handling in my code. Brad,
Hey! email me any time! Bradsvb@yahoo.com

 

[Alt255]

Don't give up now. GOTO's are fine if your logic demands them.

Regading the purists: is your code so flawless you are able to reject the methods of our fore-fathers without bloating the code?

 

[chiph]

I generally avoid using "Goto", preferring the "JumpFrom" statement.
s-)

Chip H.

 

[petermeachem]

I did a bit of work, helping out really, on some very low level stuff on an SEL computer. This had units of bits, nibbles and bytes and you could move in hops, skips and jumps depending on how far you wanted to go. Peter Meachem
peter@accuflight.com