3 ms·

Exactly fits the philosophy of Google Go - http://blog.golang.org/error-handling-and-go http://blog.golang.org/error-handling-and-go I think his point of there

Exactly fits the philosophy of Google Go - http://blog.golang.org/error-handling-and-go http://blog.golang.org/error-handling-and-go I think his point of there being easy syntax for multiple returns is critically important to make this sort of error handling non annoying - which Go does remarkably well. I think this factor has a lot to contribute to the fact that you get the warm fuzzy feeling after your code compiles. You feel confident that you have already handled all the error cases (that you care about) in your code. EDIT - Obligatory nitpick accepted. ;)

rancor 13y ago
That was my first thought as well, glad to see that Joel is on the same page. After writing a fair amount of Go recently, I've come to believe that usage of explicit error returns only appears to increase code density. In reality, it exposes the complexity of correct error handling and forces you to factor your error handling logic accordingly, rather then letting you sweep it all into a few top level handlers.
chimeracoder 13y ago
<nitpick type="obligatory">The name of the language is Go, not "Google Golang"</nitpick> That said, this was, for me, the single weirdest thing to get used to when starting to program in Go, coming from a mostly Python/Java exception-style background. (I imagine it's easier if you're a C programmer). However, once I got into the swing of it, I realized I really, really like Go's error handling, and I can't imagine going back to Python's exceptions voluntarily. Returning errors makes code much more readable, and it also reduces the risk of code suddenly failing because of an exception that got thrown somewhere that you can't even find easily. Go also gets a more subtle point correct: errors are interfaces, not types, which means that you can use any type as an error, as long as it supports the "Error() string" method. This is irrelevant 99% of the time, but I've seen a few pieces of code which utilize this feature very effectively.
- mdkess 13y ago
  I have to say, I much prefer people referring to it as Golang, otherwise it is impossible to search for.
  - lrichardson 13y ago
    this is honestly the most annoying thing about go for me. Really hard to do a quick google search for an answer to something!
    - d0m 13y ago
      Try "Django" with that new "Django Unchained" movie ;-)
      - trobertson 13y ago
        For all these language issues, I generally preface the query with the language name. "Python3 Django", "Haskell Quickcheck", "C++ Boost", etc. It makes things so much easier for the search engine to give me Good Results (tm) when it has that extra bit of context.
    - stormbrew 13y ago
      I'm endlessly amused by the irony of a search engine company naming their projects unsearchable words. Many site search engines won't even consider terms less than three characters long.
reginaldjcooper 13y ago
But why is this preferable to an either monad? The majority of the time when a subfunction fails with error, I return the error from the function calling it, so I'd rather just have a do notation or something take care of that for me.
michaelwww 13y ago
> You feel confident that you have already handled all the error cases (that you care about) in your code. What about the errors you don't care about at the time, but realize later than you should care about? Do you go back and add them? This process seems error prone to me. From the Go FAQ "[Excpetions] also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional." So the problem is not with exceptions, but how some programmers use them.

rancor 13y ago

That was my first thought as well, glad to see that Joel is on the same page. After writing a fair amount of Go recently, I've come to believe that usage of explicit error returns only appears to increase code density. In reality, it exposes the complexity of correct error handling and forces you to factor your error handling logic accordingly, rather then letting you sweep it all into a few top level handlers.

chimeracoder 13y ago

<nitpick type="obligatory">The name of the language is Go, not "Google Golang"</nitpick> That said, this was, for me, the single weirdest thing to get used to when starting to program in Go, coming from a mostly Python/Java exception-style background. (I imagine it's easier if you're a C programmer). However, once I got into the swing of it, I realized I really, really like Go's error handling, and I can't imagine going back to Python's exceptions voluntarily. Returning errors makes code much more readable, and it also reduces the risk of code suddenly failing because of an exception that got thrown somewhere that you can't even find easily. Go also gets a more subtle point correct: errors are interfaces, not types, which means that you can use any type as an error, as long as it supports the "Error() string" method. This is irrelevant 99% of the time, but I've seen a few pieces of code which utilize this feature very effectively.

mdkess 13y ago
I have to say, I much prefer people referring to it as Golang, otherwise it is impossible to search for.
- lrichardson 13y ago
  this is honestly the most annoying thing about go for me. Really hard to do a quick google search for an answer to something!
  - d0m 13y ago
    Try "Django" with that new "Django Unchained" movie ;-)
    - trobertson 13y ago
      For all these language issues, I generally preface the query with the language name. "Python3 Django", "Haskell Quickcheck", "C++ Boost", etc. It makes things so much easier for the search engine to give me Good Results (tm) when it has that extra bit of context.
  - stormbrew 13y ago
    I'm endlessly amused by the irony of a search engine company naming their projects unsearchable words. Many site search engines won't even consider terms less than three characters long.

reginaldjcooper 13y ago

But why is this preferable to an either monad? The majority of the time when a subfunction fails with error, I return the error from the function calling it, so I'd rather just have a do notation or something take care of that for me.

michaelwww 13y ago

> You feel confident that you have already handled all the error cases (that you care about) in your code. What about the errors you don't care about at the time, but realize later than you should care about? Do you go back and add them? This process seems error prone to me. From the Go FAQ "[Excpetions] also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional." So the problem is not with exceptions, but how some programmers use them.