4 ms·

I agree. Error handling in Go can be very cumbersome. I like the explicitness of it, but it can definitely be smoother.

vetinari 10y ago
I like Go error handling. Instead of getting some abstract exception and stack trace over several pages, the error message is usually pretty specific. Yes, it forces to handle errors locally, but that is a good thing, because locally you know what can go wrong. Your user, who is going to be separated by several layers, won't know that and the specificity is a godsend to him.
- szemet 10y ago
  I guess many people don't have problem with the 'errors are values' concept, just would like to handle them with much less boilerplate: like in Rust or Haskell...
- noisy_boy 10y ago
  One use case where this is a bit of an problem for me is with a user facing api. Say a web request calls a top level method/subroutine which calls more and so on. Now if there is an error in the the lower level subroutine and I wish to expose it to the user gracefully (say a json response), in Go, I need to handle it explicitly and pass it as part of my return statement (along with the actual results which may be empty/null due to the error). Doing this with each of the nested methods becomes tedious. Please correct me if I'm wrong about this understanding as my knowledge of Go is limited. If I could raise an exception, taking example of Python, I can choose not to worry about handling it in the intermediate methods and it'll float right to the top level subroutine with error message etc and I can handle it there anyway I wish.
- misterbowfinger 10y ago
  Yup, totally agreed. The specificity is great. I meant more around the actual syntax, which, as another comment mentioned, requires a lot of boilerplate.
- majewsky 10y ago
  I've actually come to dislike it a bit more in the last few days when dealing with SQL statements. If you're not meticulously adding context to all errors at every part of the step, you end up with a result like $ go build -o my-program . $ ./my-program error: SQL syntax error at column 9 $ Now have fun figuring out which of your dozens of db.Prepare() caused that. Of course, when you manually add context at every step of the error return chain, you can just as well show a stacktrace for the same amount of (if not more) information.

I like Go error handling. Instead of getting some abstract exception and stack trace over several pages, the error message is usually pretty specific. Yes, it forces to handle errors locally, but that is a good thing, because locally you know what can go wrong. Your user, who is going to be separated by several layers, won't know that and the specificity is a godsend to him.

szemet 10y ago
I guess many people don't have problem with the 'errors are values' concept, just would like to handle them with much less boilerplate: like in Rust or Haskell...
noisy_boy 10y ago
One use case where this is a bit of an problem for me is with a user facing api. Say a web request calls a top level method/subroutine which calls more and so on. Now if there is an error in the the lower level subroutine and I wish to expose it to the user gracefully (say a json response), in Go, I need to handle it explicitly and pass it as part of my return statement (along with the actual results which may be empty/null due to the error). Doing this with each of the nested methods becomes tedious. Please correct me if I'm wrong about this understanding as my knowledge of Go is limited. If I could raise an exception, taking example of Python, I can choose not to worry about handling it in the intermediate methods and it'll float right to the top level subroutine with error message etc and I can handle it there anyway I wish.
misterbowfinger 10y ago
Yup, totally agreed. The specificity is great. I meant more around the actual syntax, which, as another comment mentioned, requires a lot of boilerplate.
majewsky 10y ago
I've actually come to dislike it a bit more in the last few days when dealing with SQL statements. If you're not meticulously adding context to all errors at every part of the step, you end up with a result like $ go build -o my-program . $ ./my-program error: SQL syntax error at column 9 $ Now have fun figuring out which of your dozens of db.Prepare() caused that. Of course, when you manually add context at every step of the error return chain, you can just as well show a stacktrace for the same amount of (if not more) information.