GoTo Statement

[Zvoni]

If we're honest, the 99% use-case for GOTO is Error-handling.

I've seen enough C-Code, where they use a conditional GOTO to jump to a label to do some clean-up (usually at the end of a Function/Procedure).

440bx is correct with our Try..Except/Finally --> much more elegant.

OTOH, everytime i ported C-Code with a GOTO-Error-Cleanup i solved it without a Goto but with a nested Function and an Exit-Statement.
Much cleaner IMO.

[marcov]

One method is to use an endless loop with various combinations of break, continue and exit statements that really mess with my understanding of the logical flow.

This is the way Wirthian languages evolved, not just Pascal, but also e.g. Modula-2 loop ..end exit .

I don't see anything wrong with it, unless the problem suits a more high level solution (like a statemachine)

If this becomes necessary to express the logic, it may be time to consider other techniques, for example a state machine.

The most important bit is that everything is just guidelines, not absolute, hard rules. And normal procedure/methods that are extremely long are also a sign that is something wrong.

And yes, a statemachine can be a solution in many cases.

[devEric69]

Perso., I'm using goto in 2 cases:
- refactoring of very, very degraded, even unintelligible source code, which must be shunted little by little piece towards a replacement refactoring (e.g.: code with only one var variant variable: yes, yes, it happens).
- to compensate for the lack of semantic of the continue; statement (continue; yes, but why?) in very large loops (such as data cohort processing), when the latter statement appears several times.

[440bx]

440bx is correct with our Try..Except/Finally --> much more elegant.

I'm afraid you misunderstood me.  I consider most use of exceptions as being much worse than the majority of GOTOs.  They are in the class of setjmp/longjmp, i.e, programming atrociities.

The only time I consider the use of exceptions to be acceptable is when dealing with resources - usually memory - that is not managed by the executable that is reading (or writing) it.  The other time when it is _temporarily_ acceptable is to validate the size of the parameters received from the caller and, that is usually in an "{$ifdef debug_check_params} ... {$endif} block.  IOW, the final code does _not_ include the exception handlers.

[JLWest]

@Thanks All

All this is a nice theoretical discussion. However, it doesn't solve the problem with parsing, formatting and displaying a string in a memo at an exact location based on the composition and length of the string.
 
Yea, I could get a book, study nested functions and give it a go that way. But I think it's a logic or algorithm problem that I can't figure out.

What I'm trying to do is complicated (for me anyway) with a lot of variables.
 

[440bx]

All this is a nice theoretical discussion. However, it doesn't solve the problem with parsing, formatting and displaying a string in a memo at an exact location based on the composition and length of the string.

if you showed a sample of the string you want to parse along with the result you'd like to obtain, you'd get less theory and more code.

IOW, you're digging your own theoretical book.

[JLWest]

@440bx your right

Actually I'm working on providing a demo of the problem.

[MarkMLl]

Actually I'm working on providing a demo of the problem.

It really would help enormously. However if I could make one point: Pascal was a close derivative of ALGOL-60, and both allow nested procedures. It's more recent languages (C etc.) which have, generally speaking, omitted them.

MarkMLl