4 ms·

>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

>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.)
- hackinthebochs 13y ago
  I don't see how pluggable or proxying support your argument. What would be the alternative that would more clearly communicate intent and avoid bugs? Just avoiding these constructs altogether isn't an answer to this question. Yes, some constructs/patterns should generally be avoided, but when they are necessary higher level constructs like these are a boon rather than a hindrance. >Keep in mind that the worst problem is actually with badly caught exceptions. My point here was that if we granted that checked exceptions, i.e. forcing handling of an exception by the compiler, is a net negative, the construct of exceptions themselves (sans forced handling) is still superior to error codes for the reasons I mentioned.
  - stcredzero 13y ago
    when they are necessary higher level constructs like these are a boon rather than a hindrance. We are not in disagreement. Higher level constructs become a nuisance when they aren't really necessary: In other words, when the cost/benefit doesn't work out. Pluggability and proxying are cited as a nuisance when they should not have been there in the first place, often put there by junior programmers who are excited at their discovery. You can think of exceptions as a higher level construct expected to appear everywhere. This makes them more prone to abuse than proxying, for instance. the construct of exceptions themselves (sans forced handling) is still superior to error codes for the reasons I mentioned. Again, this is still relative to cost/benefit in individual situations. In the case of go, there would be other costs external to the simplicity of code.

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.)

hackinthebochs 13y ago
I don't see how pluggable or proxying support your argument. What would be the alternative that would more clearly communicate intent and avoid bugs? Just avoiding these constructs altogether isn't an answer to this question. Yes, some constructs/patterns should generally be avoided, but when they are necessary higher level constructs like these are a boon rather than a hindrance. >Keep in mind that the worst problem is actually with badly caught exceptions. My point here was that if we granted that checked exceptions, i.e. forcing handling of an exception by the compiler, is a net negative, the construct of exceptions themselves (sans forced handling) is still superior to error codes for the reasons I mentioned.
- stcredzero 13y ago
  when they are necessary higher level constructs like these are a boon rather than a hindrance. We are not in disagreement. Higher level constructs become a nuisance when they aren't really necessary: In other words, when the cost/benefit doesn't work out. Pluggability and proxying are cited as a nuisance when they should not have been there in the first place, often put there by junior programmers who are excited at their discovery. You can think of exceptions as a higher level construct expected to appear everywhere. This makes them more prone to abuse than proxying, for instance. the construct of exceptions themselves (sans forced handling) is still superior to error codes for the reasons I mentioned. Again, this is still relative to cost/benefit in individual situations. In the case of go, there would be other costs external to the simplicity of code.