3 ms·

>Automagic implicit hopping around to different locations in your code-base is the fatal flaw with so many overly clever programming tricks You could say the s

>Automagic implicit hopping around to different locations in your code-base is the fatal flaw with so many overly clever programming tricks You could say the same thing about lambdas, continuations... basically any high level flow control concept. Higher level flow control concepts are a good thing in just about every case. >Java's enforcement of exceptions looks like the right thing on the surface, but it instead encourages people to handle exceptions in dangerous ways when they're in a hurry. This line of reasoning has never made sense to me. Forcing error handling is the right thing. Just because someone uses that information and does something boneheaded with it is not an indictment of the concept. An explicit reminder to handle an error case is loads better than non explicit. It's like blaming the static type checker for someone casting away type errors in a language like C. It's not a fault of the concept of static type checking if people fail to handle it properly.

jbooth 13y ago
I think the poster was saying that java exceptions don't tend to force error handling to the same degree as the multiple-returns approach does. "But it's a checked exception!" Like 90% of the code I've written in Java (and it's a lot) just says 'throws IOException' up top and moves on. Or, if that's not enough, we catch some dumb ones that shouldn't even be checked (URISyntaxException anyone) and wrap them with RuntimeExceptions. Effectively I've eliminated exceptions.
stcredzero 13y ago
You could say the same thing about lambdas, continuations... basically any high level flow control concept. True, but programming, especially in the large, is about juggling a whole lot of cost-benefit calculations. Continuations done right actually reduce the implicit hopping around you have to think about in a given situation. Lambdas can increase it, but even in those cases, save you a different kind of cost. Higher level flow control concepts are a good thing in just about every case. No, they are often a good thing, but they are not a good thing in just about every case. Like any tool used for programming, you use them when the cost-benefit works out. Forcing error handling is the right thing. Just because someone uses that information and does something boneheaded with it is not an indictment of the concept. Empiricism. How does it work out in practice? What is the prevalence of bugs caused by the particular boneheaded behavior? What are the effects on difficulty of debugging? It's not a fault of the concept of static type checking if people fail to handle it properly. Why not? We could use such logic to blame a huge number of additional aircraft accidents on pilot error. But pilots, like programmers, have limited bandwidth. The cost to exception handling -- which I acknowledge is beautifully useful at times -- is that it entails an implicit hopping around of control flow. So if you combine that with compiler enforcement of exception handling, is that you force the programmer to pay the price of such implicit hopping, whether it is appropriate or not. Lazy programmers will cause problems in either case, but in the case without exception handling, it's often easier to figure out where you went wrong. Think of it this way: Enforced exception handling makes the wrong thing to do dead easy, and the right thing to do anywhere from slightly harder to a lot harder. Not having exception handling makes the wrong thing to do zero effort, but suicidal, while the right thing to do is still anywhere from slightly harder to a lot harder. An even shorter version: with Go's error handling strategy, lazy programmers tend to see the consequences sooner.
- hackinthebochs 13y ago
  >No, they are often a good thing, but they are not a good thing in just about every case. Like any tool used for programming, you use them when the cost-benefit works out. Can you offer an example (besides exception handling) where high level flow control concepts reduces readability or increases potential for bugs? I honestly can't think of any. While I understand the empiricism argument, I'm not sure thats enough to sway me. People can be "easily" enough taught not to swallow exceptions. Also the explicitness of swallowing makes catching it during code review extremely easy. Actually I'd be surprised if lint tools don't already pick it up. High level flow control concepts communicate intent, which then makes detecting deviations from that intent easy enough for tooling to catch. This is always a win. Without high level flow control, one has to deduce intent from more primitive units, increasing cognitive load and increasing potential for bugs. Even if I were to accept that the tendency for abuse makes checked exceptions a worse case, I don't see how in-band/manual error code checking is superior to unchecked exceptions. Uncaught exceptions provide much more context and they're tied to the point of inception. Ignored error codes have a tendency to cause problems downstream that can be painful to trace back to their origin. (Unchecked) exceptions seem like an obvious win here.
  - stcredzero 13y ago
    Can you offer an example (besides exception handling) where high level flow control concepts reduces readability or increases potential for bugs? I honestly can't think of any. Yes, there is a "pluggable" pattern in Smalltalk where you just let people park lambdas in instance variables to accomplish customization. Too much of this will result in complaints from fellow programmers about debuggability. Also, method_missing/doesNotUnderstand: wrappers or proxying produce the same complaints. High level flow control concepts communicate intent Good ones do. Bad ones hide it. This is always a win. Uh, no. Even this can be done badly. Without high level flow control, one has to deduce intent from more primitive units, increasing cognitive load and increasing potential for bugs. Sometimes true. Sometimes the cost/benefit works out in their favor. Even if I were to accept that the tendency for abuse makes checked exceptions a worse case, I don't see how in-band/manual error code checking is superior to unchecked exceptions. Uncaught exceptions provide much more context and they're tied to the point of inception. Keep in mind that the worst problem is actually with badly caught exceptions. What you are saying is: "Granted that too many tend to use exceptions badly, if people use exceptions intelligently, they are better." For one thing, are you granting it or not? For another thing: If your shop can manage to accomplish that, power to you! Go knock yourself out! The Go team has determined a different cost/benefit analysis in the context of their language. (It has more to do than just with the semantics of exceptions.)

jbooth 13y ago

I think the poster was saying that java exceptions don't tend to force error handling to the same degree as the multiple-returns approach does. "But it's a checked exception!" Like 90% of the code I've written in Java (and it's a lot) just says 'throws IOException' up top and moves on. Or, if that's not enough, we catch some dumb ones that shouldn't even be checked (URISyntaxException anyone) and wrap them with RuntimeExceptions. Effectively I've eliminated exceptions.

stcredzero 13y ago

You could say the same thing about lambdas, continuations... basically any high level flow control concept. True, but programming, especially in the large, is about juggling a whole lot of cost-benefit calculations. Continuations done right actually reduce the implicit hopping around you have to think about in a given situation. Lambdas can increase it, but even in those cases, save you a different kind of cost. Higher level flow control concepts are a good thing in just about every case. No, they are often a good thing, but they are not a good thing in just about every case. Like any tool used for programming, you use them when the cost-benefit works out. Forcing error handling is the right thing. Just because someone uses that information and does something boneheaded with it is not an indictment of the concept. Empiricism. How does it work out in practice? What is the prevalence of bugs caused by the particular boneheaded behavior? What are the effects on difficulty of debugging? It's not a fault of the concept of static type checking if people fail to handle it properly. Why not? We could use such logic to blame a huge number of additional aircraft accidents on pilot error. But pilots, like programmers, have limited bandwidth. The cost to exception handling -- which I acknowledge is beautifully useful at times -- is that it entails an implicit hopping around of control flow. So if you combine that with compiler enforcement of exception handling, is that you force the programmer to pay the price of such implicit hopping, whether it is appropriate or not. Lazy programmers will cause problems in either case, but in the case without exception handling, it's often easier to figure out where you went wrong. Think of it this way: Enforced exception handling makes the wrong thing to do dead easy, and the right thing to do anywhere from slightly harder to a lot harder. Not having exception handling makes the wrong thing to do zero effort, but suicidal, while the right thing to do is still anywhere from slightly harder to a lot harder. An even shorter version: with Go's error handling strategy, lazy programmers tend to see the consequences sooner.

hackinthebochs 13y ago
>No, they are often a good thing, but they are not a good thing in just about every case. Like any tool used for programming, you use them when the cost-benefit works out. Can you offer an example (besides exception handling) where high level flow control concepts reduces readability or increases potential for bugs? I honestly can't think of any. While I understand the empiricism argument, I'm not sure thats enough to sway me. People can be "easily" enough taught not to swallow exceptions. Also the explicitness of swallowing makes catching it during code review extremely easy. Actually I'd be surprised if lint tools don't already pick it up. High level flow control concepts communicate intent, which then makes detecting deviations from that intent easy enough for tooling to catch. This is always a win. Without high level flow control, one has to deduce intent from more primitive units, increasing cognitive load and increasing potential for bugs. Even if I were to accept that the tendency for abuse makes checked exceptions a worse case, I don't see how in-band/manual error code checking is superior to unchecked exceptions. Uncaught exceptions provide much more context and they're tied to the point of inception. Ignored error codes have a tendency to cause problems downstream that can be painful to trace back to their origin. (Unchecked) exceptions seem like an obvious win here.
- stcredzero 13y ago
  Can you offer an example (besides exception handling) where high level flow control concepts reduces readability or increases potential for bugs? I honestly can't think of any. Yes, there is a "pluggable" pattern in Smalltalk where you just let people park lambdas in instance variables to accomplish customization. Too much of this will result in complaints from fellow programmers about debuggability. Also, method_missing/doesNotUnderstand: wrappers or proxying produce the same complaints. High level flow control concepts communicate intent Good ones do. Bad ones hide it. This is always a win. Uh, no. Even this can be done badly. Without high level flow control, one has to deduce intent from more primitive units, increasing cognitive load and increasing potential for bugs. Sometimes true. Sometimes the cost/benefit works out in their favor. Even if I were to accept that the tendency for abuse makes checked exceptions a worse case, I don't see how in-band/manual error code checking is superior to unchecked exceptions. Uncaught exceptions provide much more context and they're tied to the point of inception. Keep in mind that the worst problem is actually with badly caught exceptions. What you are saying is: "Granted that too many tend to use exceptions badly, if people use exceptions intelligently, they are better." For one thing, are you granting it or not? For another thing: If your shop can manage to accomplish that, power to you! Go knock yourself out! The Go team has determined a different cost/benefit analysis in the context of their language. (It has more to do than just with the semantics of exceptions.)