Timeline for Are exceptions as control flow considered a serious antipattern? If so, Why?
Current License: CC BY-SA 4.0
38 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 7, 2022 at 14:18 | comment | added | b_levitt | It would appear that Wards is having the debate as well so I don't see this as a fitting reference without it's own counterpoint: wiki.c2.com/?UseExceptionsInsteadOfErrorValues | |
| Nov 2, 2021 at 1:12 | comment | added | PandaWood | The first 2 reasons are just "poisoning the well" and goes onto criticize all exceptions, which doesn't answer the question | |
| Oct 10, 2020 at 12:46 | comment | added | user90726 | Ward's Wiki is alive, so I don't see a reason to use an archived version of the page. Here is the current one: wiki.c2.com/?DontUseExceptionsForFlowControl | |
| Jul 18, 2019 at 16:51 | history | edited | blueberryfields | CC BY-SA 4.0 |
added some additional, clarifying, external references
|
| Jul 15, 2019 at 12:32 | comment | added | Shayne | "Okay but seriously, what is up with server-side and app devs burying errors with empty catch statements in the JavaScript?". Its called "Why you don't let your graphic designer write server code". Its just straight up bad coding. And unfortunately like PHP, Javascript tends to attract a lot of self taught coders who never had a chance to learn the theory of why things are like they are. Although I'm not a fan of it, JS can be a powerful tool, but it needs to be used wisely or you'll end up with an absolute garbage fire. | |
| Apr 28, 2019 at 15:50 | comment | added | blueberryfields | @TaylanUB - the sentence is shorthand for giving an intuitive idea of how to treat exceptions, and not meant to define technical terms. Sure, technically and if you really want to, you can call any control structure you want sophisticated GOTO's; it's just not a useful way to describe most of them. Exceptions stand out because it is a useful way to describe them; the difference between which control structures can be usefully described that way, is left as an exercise to the reader, with help from the external references. | |
| Apr 28, 2019 at 15:41 | comment | added | Eamon Nerbonne | @TaylanUB hence "sophisticated". That discussion isn't about the material, it's about how you squint. If you're going to call exceptions "sophisticated" goto,s then pretty much any control flow is. Which isn't a problem per se - but if you're going to distinguish maintainability and thus degree of anti-pattern-ness between goto and conventional control-flow, then you need to do the same and distinguish between gotos and exceptions. | |
| Apr 2, 2019 at 13:36 | comment | added | TaylanKammer |
Gotta retort to the goto comparison as a language nerd. You can implement continue, break, and return with a goto, hence they are merely syntax sugar for goto. You can implement while and foreach with a label, if, and goto, so they're also just sugar. Exceptions are a bit more complicated. They're a goto across function barriers. And if we're down to that level, even function calls are goto! (You can't implement if with goto though, @EamonNerbonne.)
|
|
| Mar 17, 2019 at 19:10 | comment | added | Zhuinden | I always refer to this guide to see that "yup, exceptions were made to make it easier to reason about code flow", any tool can be misused. | |
| Apr 26, 2018 at 16:48 | review | Suggested edits | |||
| Apr 30, 2018 at 5:47 | |||||
| S Jan 10, 2017 at 4:58 | history | suggested | Fuhrmanator | CC BY-SA 3.0 |
missing word, comma and dash
|
| Jan 10, 2017 at 4:07 | review | Suggested edits | |||
| S Jan 10, 2017 at 4:58 | |||||
| Nov 21, 2016 at 20:20 | comment | added | Tomáš Zato |
Sounds like comparing coding practices to use of goto is the new "hitler liked that too" argument.
|
|
| S Oct 20, 2016 at 14:56 | history | edited | blueberryfields | CC BY-SA 3.0 |
formatting
|
| S Oct 20, 2016 at 14:56 | history | suggested | Devon Parsons | CC BY-SA 3.0 |
Link is broken, changed to archived version
|
| Oct 20, 2016 at 14:03 | review | Suggested edits | |||
| S Oct 20, 2016 at 14:56 | |||||
| Jun 16, 2016 at 9:48 | comment | added | user207421 | Exceptions are flow control. Any statement that suggest the contrary is self-contradictory. | |
| Jan 11, 2015 at 12:12 | comment | added | Eamon Nerbonne |
@mattnz: if and foreach are also sophisticated GOTOs. Frankly, I think the comparison with goto isn't helpful; it's almost like a derogatory term. GOTO usage isn't intrinsically evil - it has real problems, and exceptions might share those, but they might not. It would be more helpful to hear those problems.
|
|
| Mar 6, 2013 at 23:25 | comment | added | Winston Ewert | @BillK, the OP said that "exceptions are sophisticated gotos", your disagreement with MasonWheeler made it look like you were agreeing with that sentiment. | |
| Mar 6, 2013 at 23:21 | comment | added | Bill K | @WinstonEwert That's pretty much what I said, I never said exceptions are gotos (Well, at least I'm pretty sure I didn't). My claim was that they were similar (had the same faults--which is, producing unreadable code). | |
| Mar 6, 2013 at 22:04 | comment | added | Winston Ewert | @BillK, my objection is that you should say "exceptions produce unreadable code" rather than "exceptions are gotos." The readability is what matters. Whether or not something bears a resemblance to gotos is irrelevant. | |
| Mar 6, 2013 at 22:01 | comment | added | Winston Ewert | @BillK, What makes you think that I think that gotos are less functional or evil? What I said was that "almost no situations are more clearly expressed using them." That's exactly what you are saying! We agree, gotos should be avoided because we have more readable alternatives. | |
| Mar 6, 2013 at 21:54 | comment | added | Bill K | @WinstonEwert You are right, goto can offer everything that the other structures can. The thing is limitations are the most important thing a language can offer. The point is not to write code to make something work--that's easy; the point is to make code that others can read and comprehend easily. A label coming into your code from elsewhere forces you to comprehend a lot of external flow whereas a structured loop limits what you have to comprehend. Exceptions are in-between. This comprehension problem is the only problem people have with Gotos, not that they are less functional or evil. | |
| Mar 6, 2013 at 1:28 | comment | added | Winston Ewert | @BillK, as I see it all control structures are deliberately limited versions of goto. If you want to complain about exceptions, its not enough to argue that its a version of goto, (everything is) you need to argue why its particular set of limitations are a bad idea. | |
| Mar 6, 2013 at 1:10 | comment | added | Winston Ewert | @BillK, I'm pretty sure Java doesn't have scoped gotos. It does have labelled break statements, but I wouldn't call those gotos because they are more restricted than a true goto. As for gotos, their fault is that almost no situations are more clearly expressed using them. With exceptions, I argue that some situations are more clearly expressed using them. Hence if you assert, as the OP did, that exceptions are just gotos, I think you need to explain more of what you mean rather than just making that assertion. | |
| Mar 5, 2013 at 22:19 | comment | added | Bill K | @WinstonEwert Why are goto's bad? For instance, java has scoped gotos--they are only valid within that file and within a restricted area of code. Why not use it? Whatever arguments I can come up with against gotos certainly apply exceptions as well. What are your problems with goto's that make you feel the parallel is so unjust? | |
| Mar 5, 2013 at 21:27 | comment | added | Winston Ewert | @BillK, certainly exceptions can be badly abused. But saying that exceptions are gotos is a horrendously over-simplistic way of expressing that argument. I figure that exceptions for flow control are OK if you catch them one level up from when they are thrown (since the effect is pretty much the same as a return), but beyond that its problematic. | |
| Mar 5, 2013 at 4:43 | comment | added | Erik Reppen | Okay but seriously, what is up with server-side and app devs burying errors with empty catch statements in the JavaScript? It's a nasty phenomon that has cost me a lot of time and I don't know how to ask without ranting. Errors are your friend. | |
| Mar 5, 2013 at 4:40 | comment | added | Bill K | (cont) Also note that Java helps you by keeping as much as possible local to a single class so that you can fully understand it as a whole. Exceptions, used as flow control, would force you to reach way outside that file, to the caller and to the things it calls to fully understand the flow for that little section of code. When coding your goal should not be to make the code work, that's your teams job. Your job is making code your team can understand.. With that goal in mind, I don't think anyone could say using exceptions for flow control is a good way to help others understand your code. | |
| Mar 5, 2013 at 4:29 | comment | added | Bill K | @WinstonEwert I really like exceptions for error handling, I think that was the first difference I noticed between Java and C... even a slapped-together java program can be made to run practically indefinitely with minimal effort. Thing is, they add complexity. Biggest problem I've seen is where you are tracing through a routine and suddenly a lower-level routine throws an exception that a higher level one silently eats--it can take DAYS to track down why your thread just "Stopped" at that point... | |
| Mar 5, 2013 at 3:45 | comment | added | Winston Ewert |
@James, how does having to specify the right exception type pose a problem? After all, you've got to specify the right condition for an if statement.
|
|
| Mar 5, 2013 at 0:31 | comment | added | James |
@MasonWheeler there's nothing sophisticated about for and while. Exceptions are different in that you need to make sure your catch block looks out for the right exception type. Also, in the case of C++ the compiler will generate extra invisible stack unwinding code that may be large and therefore a potential issue in resource constrained environments.
|
|
| Mar 5, 2013 at 0:14 | comment | added | Winston Ewert | @BillK, then argue that, and don't make over simplistic statements about how exceptions are gotos. | |
| Mar 5, 2013 at 0:02 | comment | added | Bill K | @MasonWheeler The difference is that for/while loops contain their flow control changes clearly and make the code easy to read. If you see a for statement in your code, you don't have to try to figure out which file contains the end of the loop. Goto's aren't bad because some god said they were, they are bad simply because they are harder to follow than the looping constructs. Exceptions are similar, not impossible but hard enough that they can confuse things. | |
| Mar 4, 2013 at 22:52 | history | edited | blueberryfields | CC BY-SA 3.0 |
added details based on comments.
|
| Mar 4, 2013 at 22:46 | comment | added | whatsisname | Your answer makes it sound as though exceptions are bad for all circumstances, while the quesion is focused on exceptions as flow control. | |
| Mar 4, 2013 at 22:46 | vote | accept | Aaron Anodide | ||
| Mar 4, 2013 at 22:40 | history | answered | blueberryfields | CC BY-SA 3.0 |