Do not worry about the abobe code, it is just an example I made, please do not try to fix it, it is just illustrative of the crash, not the actual code on the program.
because it's quite obvious you should not exit a procedure with a goto, but about the select/endselect it's not obvious at all, since some compilers implements the select using gotos or jump tables but without using the stack.
Would be nice to have clearly stated if there are other constructs who deserve special attention with gotos.
offtopic: would be also nice to know which native commands/functions are replaced with inline code by the compiler.
Would be nice to have clearly stated if there are other constructs who deserve special attention with gotos.
Basically, Goto commands should be avoided in any file containing Purebasic sourcecode. It should be OK in a note to yourself, e.g. "goto store for milk".
I disagree, in a language without exceptions handling the GOTO is the only way to keep your sanity and to exit from deep-nested nice structured code when something bad happens without using disguised gotos like breaks or god-forbid "break n" or dubious flags to be checked at every level.
In those cases I find GOTOs to a common exit point in the proc where the cause of the error can then be analyzed and acted upon a lot easier to understand and maintain too.
In theory, but I don't know if you ever tried to use it...
I did and found too much problems with that. Even if you look at the manual you'll see it's better suited to trap fatal errors to be followed by the the program termination.
Not to mention sometime there are interactions with the debugger.
I found very unreliable trying to generate a custom error with RaiseError(), trapping it with OnErrorGoto() and actually trying to continue from here.
luis wrote:I disagree, in a language without exceptions handling the GOTO is the only way to keep your sanity and to exit from deep-nested nice structured code when something bad happens without using disguised gotos like breaks or god-forbid "break n" or dubious flags to be checked at every level.
In those cases I find GOTOs to a common exit point in the proc where the cause of the error can then be analyzed and acted upon a lot easier to understand and maintain too.
Luis, now I disagree
You see, Goto is evil
Seriously, there's little need for Goto. If things are many levels deep, why not use an 'exit flag'? Something like...