3 ms·

I don't see what's interesting with this?

Artemis2 12y ago
Yeah, I don't get the point of this; that's how it's done in Go. You might want to search "catch (Exception e)" for other languages.
- royjacobs 12y ago
  Except in Go you would be manually "rethrowing" exceptions whereas in other languages that is done automatically.
  - leaveyou 12y ago
    It's verbose and explicit but this is like using tests for your programs: boring and annoying short term but very useful medium and long term.
    - royjacobs 12y ago
      Yes, that can definitely be the case. It's just a hard problem in general. So far the explicitness of Go's error handling reminds me a little bit of checked exceptions in Java: I appreciate the idea but I'm not sure it's the best thing we could do.
    - jerven 12y ago
      Verbose and explicit is what made java checked exceptions the sign of the demon for some programmers. The err pattern in GO might end up the same. In the end I think the problem is that there are two separate classes of programs. The first is where crash on exception is tolerable and even a desired property (or blindly and optimistically continuing). The second is always deal with exceptions and any error no matter how rare and unlikely they are, and attempt to recover and deal with them properly. No one language and standard library can really please both sides.
norswap 12y ago
I think it shows that while the Go people usually say that their error handling is better than exception, most often they either exit on exception (which is like not catching an exception) or pass the error up the call stack (the default behaviour for an uncaught exception). This means that this way of doing error handling is actually just verbose. Which is also my opinion.
- sagichmal 12y ago
  > most often they either exit on exception (which is like > not catching an exception) Not really. Exiting on error is an explicit decision that you make, hopefully only in your top-level (func main) scoping block. Letting an exception bubble up to that level without catching it is invisible. > or pass the error up the call stack (the default > behaviour for an uncaught exception) The crucial difference, which the Go team takes great pains to elucidate and fans of exceptions never seem to acknowledge, is that by treating the error as a first-order value, you make its propagation up the call stack explicit, in the normal i.e. visible code path. That makes reasoning about your error path a lot easier, and makes producing code that handles errors correctly a lot simpler. The "Eureka" of error handling in Go isn't a massive thing. It's just the reification of the small and important understanding that errors are values, just like anything else.
  - norswap 12y ago
    Well, Java tried to make it explicit with checked exceptions, and everyone hated that. And checked exception are a much better design than the way Go does it: either you catch, which is like checking the error value in Go, or you don't and annotate your function signature with "throws MyException", which is more explicit and terser. The thing that some Go fans miss is that it's actually pretty rare (in my own experience, but I've seen a lot of people echo the same thing) to have to deal with an exception. Usually an exception means that the show is over -- at best you'll report it to the user and continue running your main loop if your application is interactive. Or you may retry the operation a certain number of times. But most of the time you just want to stop the application, or let some upper level deal with it, and those are exactly the default behaviors of exceptions.

Yeah, I don't get the point of this; that's how it's done in Go. You might want to search "catch (Exception e)" for other languages.

royjacobs 12y ago
Except in Go you would be manually "rethrowing" exceptions whereas in other languages that is done automatically.
- leaveyou 12y ago
  It's verbose and explicit but this is like using tests for your programs: boring and annoying short term but very useful medium and long term.
  - royjacobs 12y ago
    Yes, that can definitely be the case. It's just a hard problem in general. So far the explicitness of Go's error handling reminds me a little bit of checked exceptions in Java: I appreciate the idea but I'm not sure it's the best thing we could do.
  - jerven 12y ago
    Verbose and explicit is what made java checked exceptions the sign of the demon for some programmers. The err pattern in GO might end up the same. In the end I think the problem is that there are two separate classes of programs. The first is where crash on exception is tolerable and even a desired property (or blindly and optimistically continuing). The second is always deal with exceptions and any error no matter how rare and unlikely they are, and attempt to recover and deal with them properly. No one language and standard library can really please both sides.

norswap 12y ago

I think it shows that while the Go people usually say that their error handling is better than exception, most often they either exit on exception (which is like not catching an exception) or pass the error up the call stack (the default behaviour for an uncaught exception). This means that this way of doing error handling is actually just verbose. Which is also my opinion.

sagichmal 12y ago
> most often they either exit on exception (which is like > not catching an exception) Not really. Exiting on error is an explicit decision that you make, hopefully only in your top-level (func main) scoping block. Letting an exception bubble up to that level without catching it is invisible. > or pass the error up the call stack (the default > behaviour for an uncaught exception) The crucial difference, which the Go team takes great pains to elucidate and fans of exceptions never seem to acknowledge, is that by treating the error as a first-order value, you make its propagation up the call stack explicit, in the normal i.e. visible code path. That makes reasoning about your error path a lot easier, and makes producing code that handles errors correctly a lot simpler. The "Eureka" of error handling in Go isn't a massive thing. It's just the reification of the small and important understanding that errors are values, just like anything else.
- norswap 12y ago
  Well, Java tried to make it explicit with checked exceptions, and everyone hated that. And checked exception are a much better design than the way Go does it: either you catch, which is like checking the error value in Go, or you don't and annotate your function signature with "throws MyException", which is more explicit and terser. The thing that some Go fans miss is that it's actually pretty rare (in my own experience, but I've seen a lot of people echo the same thing) to have to deal with an exception. Usually an exception means that the show is over -- at best you'll report it to the user and continue running your main loop if your application is interactive. Or you may retry the operation a certain number of times. But most of the time you just want to stop the application, or let some upper level deal with it, and those are exactly the default behaviors of exceptions.