4 ms·

It's actually awesome. At first it feels ugly to write, and you're generating all this unnecessary noise in your code, but then you finish a big project and ov

by jbooth 13y ago

It's actually awesome. At first it feels ugly to write, and you're generating all this unnecessary noise in your code, but then you finish a big project and overall the manual error checking combined with defer leads to less code than the Java or C++ equivalent, and feels safer. Going back to try/finally just feels awkward now.

hackinthebochs 13y ago
I don't see how its possible that manual error checking leads to less code than try/catch/finally. Can you give some examples? Even if this were true, it certainly doesn't lead to clearer code as you have your error handling code weaved into the mainline of the algorithm. Extracting error handling to the outskirts of the algorithm is a win, even if it costs a few extra lines of code.
- jbooth 13y ago
  I can't really give a good example because I'm not sure how it happens, it just has, for me. Maybe it happens in spite of the error handling. Anyways, I think that weaving the error handling code into the mainline of your algorithm is in fact clearer. It's 100% clear what's happening at all times, and you don't have to speculate about where exceptions could create a hidden return. Maybe you feel differently, although I'd recommend trying it for a while with an open mind.
  - stcredzero 13y ago
    Sounds like what you're saying is that it makes flow-of-control in error situations explicit instead of implicit. Automagic implicit hopping around to different locations in your code-base is the fatal flaw with so many overly clever programming tricks. Go is made purposely dangerous, to force people to explicitly do the right thing. 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.
    - hackinthebochs 13y ago
      >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.

by jbooth 13y ago

hackinthebochs 13y ago

I don't see how its possible that manual error checking leads to less code than try/catch/finally. Can you give some examples? Even if this were true, it certainly doesn't lead to clearer code as you have your error handling code weaved into the mainline of the algorithm. Extracting error handling to the outskirts of the algorithm is a win, even if it costs a few extra lines of code.

jbooth 13y ago
I can't really give a good example because I'm not sure how it happens, it just has, for me. Maybe it happens in spite of the error handling. Anyways, I think that weaving the error handling code into the mainline of your algorithm is in fact clearer. It's 100% clear what's happening at all times, and you don't have to speculate about where exceptions could create a hidden return. Maybe you feel differently, although I'd recommend trying it for a while with an open mind.
- stcredzero 13y ago
  Sounds like what you're saying is that it makes flow-of-control in error situations explicit instead of implicit. Automagic implicit hopping around to different locations in your code-base is the fatal flaw with so many overly clever programming tricks. Go is made purposely dangerous, to force people to explicitly do the right thing. 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.
  - hackinthebochs 13y ago
    >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.