Viewing a single comment thread. View all comments

Symbian_Curator t1_iycacc6 wrote

Reply to comment by Sloloem in ELI5: why is using "goto" considered to be a bad practice in programming? by Dacadey

I just want to point out, GOTO is not completely pointless, but the industry is used to repeating how GOTO is terrible without thinking much about the reasons, the reasons being as you pointed out, but also, valid uses for GOTO are so few and far between that it's just easier to teach new programmers to simply never use it.

About those valid uses:

  • In C, to mimic the destructor behaviour of C++ in function. For example, let's say that in function F you have: initialize resource A, initialize resource B, initialize resource C, do some work, clean u C, clean up B, clean up A. Then, in the code, you would try to init A, and if it works, carry on, but if not, exit the function. Try to init B, and if it works, carry on, but if not, GOTO "clean up A" part. Try to init C, and if it works, carry on, but if not, GOTO "clean up B" part. When you GOTO like this, the code "falls through" to clean up only the resources which were initialized. I was told that this technique is used widely in the code of the Linux kernel, but honestly I haven't bothered to check myself.
  • With some compiler extensions, computed GOTOs (where you can take the address of a GOTO label, put it in a lookup table, and jump based on some index) present a optimization opportunity for performance critical code, notably interpreters for other languages or bytecode of other languages. (it's similar to switch/case, just faster)
11

Deadmist t1_iycd9gz wrote

> In C, to mimic the destructor behaviour of C++ in function.

That doesn't mean using GOTO isn't bad, it just means that there is no better option in C.
In 'modern' languages, like C++ or Java, you can achieve the same outcome with destructors or try-with-resources, without the pitfalls of GOTO.

10

Symbian_Curator t1_iyce7cl wrote

I agree, but sometimes you just have to use C and then you use the tools you have. A bad tool is better than no tool at all.

My main point was that GOTO is not always pointless/useless.

6

Clewin t1_iyd736l wrote

Speaking of, one of the biggest uses of GOTO I saw in C was for exception handling. C++ as well, until try-catch blocks were added (and that varied by compiler until the late 1990s, early 2000s).

2

Liese1otte t1_iyd0xn1 wrote

Yea, this. GOTO is not neccessarily a bad thing. It's a thing. More popular codebases (mostly lower level) use GOTOs than people think. It can be handy in rare cases when you are in control and using GOTO won't actually hurt readability / predictability.

It's just that it's really easy to fuck up when using GOTO so you might as well just not at all (especially when you are not an expert on how things tend to work with it).

Same can be applied to other commonly accepted opinions, like using "eval"-type commands.

6

Sloloem t1_iyefdj8 wrote

Some languages also kindof have you using GOTOs and labels for exception handling...I wanna say Visual Basic? I did a project a few years ago using CrownPeak CMS which at the time I think used VB for its templating language and I vaguely recall winding up with a lot of really snotty "ON ERROR GOTO HELL" clauses. I think some legacy data applications that had a lot of functionality written in SQL procedures used that sort of error handling instead of more modern try-catch-finally or try-with-resources blocks. It's all true but I don't think I'm inaccurate in saying they're pretty niche edge cases for most programmers.

1

Symbian_Curator t1_iyefzmc wrote

At this point, Visual Basic itself is a niche edge case :D

2

Sloloem t1_iyehs4b wrote

And we're all the better for it being that way.

1