3 ms·

throw is being used as a replacement for goto.

jnwatson 7y ago
All control flow are jumps underneath it all. The only important question about a particular control flow syntax element is: does it allow a human to reason about a particular code scenario more easily. Most of the time, I think exceptions help more than hurt. Like many things in language design, it is a trade off, in this case of concision vs simplicity.
- fxtentacle 7y ago
  I've always thought of Java as being extra verbose, in part because there's try catch blocks everywhere.
  - mjevans 7y ago
    I've thought of it as being extra tedious.
  - tsimionescu 7y ago
    Wherever there is a try/catch block in Java, you would have at least a few if err return/goto cleanup in C/Go/other error-code languages. This is especially true when you have a function which performs multiple operations that return the same kind of error (e.g. multiple HTTP calls, or multiple file-based operations). In general, in Java you need a single try/catch block for all of these (which may well be in another function), but you need an if err return for each one in C. Rust has a more interesting approach, where the sue of Macros gets rid of the verbose if-based pattern, but the code also avoids non-local return. I haven't written Rust yet, but it seems like a very interesting approach.
  - erik_seaberg 7y ago
    A lot of try blocks are only there because stdlib declared a lot of interface methods that forbid checked exceptions, requiring everyone to smuggle them out. This nonsense just goes away in Scala and Kotlin.
- notacoward 7y ago
  > All control flow are jumps underneath it all. Yes, all control flow is ultimately jumps. That's exactly why structured programming was created, to constrain the patterns of those jumped. And it worked pretty well for decades, with if/else and for/while and function composition accounting for 99% of control flow. Goto breaks that pattern, as do exceptions. That's why both should be used sparingly and carefully. > I think exceptions help more than hurt. I think the exact opposite. A lot depends on what you're used to. What isn't a matter of taste/opinion is that exceptions lead to a greater separation between where an error is first detected/indicated and where it's handled, compared to error-code returns. There are times when that's appropriate - e.g. code that's just going to retry an entire high-level operation regardless of what error occurred or where. However, I believe that most of the time that's both less appropriate/efficient/debuggable than handling the error closer to its source.
kova12 7y ago
Which by the way was bullied away for no reason. goto has it's uses, but nobody would dare to use it even when it's appropriate
- wruza 7y ago
  Most of this religion is plaguing young minds when they cannot stand an objective point before authoritative statements (or any statements, as anyone can drive a smartish blog today with a great confidence). I remember how I fought for some of software religion myself and how it took time to get rid of at least worst parts of it. What is pure evil is articles like this one, claiming something in a pure vacuum instead of weighting a technique in various exact situations and analyzing the outcomes.
notacoward 7y ago
Worse, the very same people who sneer at "goto" even when used in a very controlled fashion (e.g. the cleanup-cascade pattern common in kernel code) will turn around and sprinkle their code with a construct that's basically a non-local goto with an unknown (at compile time) destination. They complain about "spaghetti code" and then create code like a toddler's attempt at macrame. Defending exceptions in non-exceptional cases is usually an exercise in hypocrisy.

All control flow are jumps underneath it all. The only important question about a particular control flow syntax element is: does it allow a human to reason about a particular code scenario more easily. Most of the time, I think exceptions help more than hurt. Like many things in language design, it is a trade off, in this case of concision vs simplicity.

fxtentacle 7y ago
I've always thought of Java as being extra verbose, in part because there's try catch blocks everywhere.
- mjevans 7y ago
  I've thought of it as being extra tedious.
- tsimionescu 7y ago
  Wherever there is a try/catch block in Java, you would have at least a few if err return/goto cleanup in C/Go/other error-code languages. This is especially true when you have a function which performs multiple operations that return the same kind of error (e.g. multiple HTTP calls, or multiple file-based operations). In general, in Java you need a single try/catch block for all of these (which may well be in another function), but you need an if err return for each one in C. Rust has a more interesting approach, where the sue of Macros gets rid of the verbose if-based pattern, but the code also avoids non-local return. I haven't written Rust yet, but it seems like a very interesting approach.
- erik_seaberg 7y ago
  A lot of try blocks are only there because stdlib declared a lot of interface methods that forbid checked exceptions, requiring everyone to smuggle them out. This nonsense just goes away in Scala and Kotlin.
notacoward 7y ago
> All control flow are jumps underneath it all. Yes, all control flow is ultimately jumps. That's exactly why structured programming was created, to constrain the patterns of those jumped. And it worked pretty well for decades, with if/else and for/while and function composition accounting for 99% of control flow. Goto breaks that pattern, as do exceptions. That's why both should be used sparingly and carefully. > I think exceptions help more than hurt. I think the exact opposite. A lot depends on what you're used to. What isn't a matter of taste/opinion is that exceptions lead to a greater separation between where an error is first detected/indicated and where it's handled, compared to error-code returns. There are times when that's appropriate - e.g. code that's just going to retry an entire high-level operation regardless of what error occurred or where. However, I believe that most of the time that's both less appropriate/efficient/debuggable than handling the error closer to its source.

kova12 7y ago

Which by the way was bullied away for no reason. goto has it's uses, but nobody would dare to use it even when it's appropriate

wruza 7y ago
Most of this religion is plaguing young minds when they cannot stand an objective point before authoritative statements (or any statements, as anyone can drive a smartish blog today with a great confidence). I remember how I fought for some of software religion myself and how it took time to get rid of at least worst parts of it. What is pure evil is articles like this one, claiming something in a pure vacuum instead of weighting a technique in various exact situations and analyzing the outcomes.

notacoward 7y ago

Worse, the very same people who sneer at "goto" even when used in a very controlled fashion (e.g. the cleanup-cascade pattern common in kernel code) will turn around and sprinkle their code with a construct that's basically a non-local goto with an unknown (at compile time) destination. They complain about "spaghetti code" and then create code like a toddler's attempt at macrame. Defending exceptions in non-exceptional cases is usually an exercise in hypocrisy.