> Almost everything is a "rebranded goto". Functions, conditions, iteration, break/continue.
That's like saying all maths is just the application of addition.
I think that's the point -- it's nearly as useless to call throw/catch a rebranded goto as it is anything else.
Yeah. It’s a useless pedantism that serves no purpose in most discussions.
That’s what I have “rebranded goto” in quotes. And that’s what I address in the second paragraph.
it failed to satisfy me
Re:Meta’s Microservice Architecture [pdf]
by randomdata on Tuesday July 11, 2023 @09:30AM
(#36680685)
> Almost everything is a "rebranded goto". Functions, conditions, iteration, break/continue.
Not within the context of discussion, where goto refers to the harmful kind. Throw/catch exhibits the very problem Dijkstra was talking about, with execution jumping all over the place haphazardly. Functions, conditions, iteration, break/continue, even (C-style) goto does not exhibit the same problem. They are strictly bridled in the execution scope.
There is good reason why modern languages are moving away from throw/catch. However, there is little question that it is still widely used at this time.
Doesn't mean that Dijkstra was wrong, or that they are the same as goto.
Also, throw/catch do quite more than a goto, though. It's not only about stack unwinding, it's about the ergonomics of not needing code that uses throw to have any information about where catch is located.
Sure you can simulate some use cases of try/catch with goto, but implementing the general case is much harder.
throw/catch is exactly the kind of good goto-replacement provided by "higher level" programming languages that Dijkstra is talking about in his paper.