4 ms·
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 a
by 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 agoI've always thought of Java as being extra verbose, in part because there's try catch blocks everywhere.
- mjevans 7y agoI've thought of it as being extra tedious.
- tsimionescu 7y agoWherever 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 agoA 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.