Viewing a single comment thread. View all comments

Nagisan t1_iybirhz wrote

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

> sooooo, function() ?

Not exactly.

Functions return to the point of execution once they finish running, GOTO just continues running the program linearly from where ever in the code the GOTO is pointing to.

For example, if the comment you replied to used a function instead of GOTO XANADU, the 'unrelated stuff' would run, then it would return to the spot it left off on, which would run the 'necessary cleanup'. But GOTO doesn't do that, GOTO would run the 'unrelated stuff' and then just hit the end of the file and never clean up.

GOTO is a one-way operation that sends the program to another line of code and never returns (unless you explicitly program another GOTO that goes back), functions send the program to another line of code but then return back to the line the function is called from once the function is done.

9

Deadmist t1_iycdnze wrote

Functions ^1 also give you a well defined arguments, return type(s) and scope for variables.
With GOTO, there is no guarantee for anything.

^1 in most languages, looking at you JS...

2

A_dudeist_Priest t1_iydg0si wrote

I am an old fart developer that learned on the old PET's, C64 and TI, the language I learned on, was BASIC\Waterloo BASIC (we are talking early 80's here), GOTO was a staple. I have watched languages go from a "wall of code", to the more structured OOP that we use today.

You brought up and interesting point that I had never thought of, when calling a Function\Subroutine, everything in the calling function is pushed onto the stack, then popped from the stack when returning from the called function, the GC would then "clean up" as you say. But I guess using a GOTO statement would not push and pop the stack, would/could this cause a modern application to have a memory leak, or cause the application to run out of process and/or Heap space?

A hint for beginner developers, be careful of recursive function calls (functions that call themselves) if done improperly, you get into a recursive loop and you will very quickly run out of stack space.

1

Nagisan t1_iydgn4p wrote

I would guess it could cause memory leak issues and such, but in all honesty I'm not much for low-level programming details beyond what I did through school and much prefer sticking around the web dev space these days....so I'm not entirely sure the full implications that GOTO would have on memory.

1

generous_cat_wyvern t1_iybqmwc wrote

>functions send the program to another line of code but then return back to the line the function is called from once the function is done.

Except for when Exceptions are thrown, but I guess that's why they're called Exceptions :p (I actually don't know if that's the reason, I probably just made that up) But even Exceptions propagate up a call stack in a predictable manner.

As an aside, it blew my mind when I found out that in ASP.NET, redirects happen by internally throwing a ThreadAbortException behind the scenes that can't be handled by normal means. It made sense that code after calling redirect didn't execute, and the only way to have code behave that way is if an Exception is thrown, I just never put two and two together.

0

Nagisan t1_iybrn9u wrote

Exceptions can open up a whole pandora's box in the flow of a program. I can't speak for every language (because there's lots I don'tknow), but at least with what I'm most familiar with the function does return to the line it was called from depending on how you handle the exception.

In the case of your function catching the exception, you can fail gracefully by logging an error, at which point the program will continue and the function will return to the line that called it then just chug right along (if the result of the function wasn't necessary for the program to continue).

In the case your function doesn't catch the exception, it will bubble up to the place it was called from and repeat this process (if the exception is caught at the higher level, my second paragraph happens, otherwise it bubbles up again, repeat until something catches the exception or the program reaches the main function and crashes).

So yeah, exceptions can be the oddity here, but they also can continue to work the same as no exceptions when it comes to the flow through a program.

1