4 ms·

Error handling is easily one of my favorite things about Go. No 'oops I forgot to put in a try/catch and now my code died with no explanation'. No 'I forgot a

Error handling is easily one of my favorite things about Go. No 'oops I forgot to put in a try/catch and now my code died with no explanation'. No 'I forgot a finally ( or didn't realize I needed one ) and now I'm leaking resources'. No 'should I return Null or false or an error code?'. No '20 log messages for the same error because every function is reporting it'. The Go model - Return err, always as the last parameter - When you need more context, add it to the error before you return it - There is a calling function that reports errors. Maybe main(), maybe a subscriber, maybe a goroutine. There can be other situations of course but the point is that there's a clear ownership. If someone is logging errors in a higher up method, they should be prepared to explain why in code reviews.

AtNightWeCode 5y ago
1. You have something that catches and logs all uncaught exceptions. 2. Defer is nice. As easy to forget as using in C#. 3. Always null/nil. Uncle Bob is plain wrong here. 4. Stack trace. But you should keep things wide and shallow. No matter what technology you use. In Go it is about as easy to swallow errors as with try-catch. But my post was more about how all the if-statements generates more unnecessary if-statements.
- ssteel 5y ago
  The if-statements are not unnecessary if you want to handle errors in place and make the code highly readable. Just because you don't like it doesn't make it wrong.
- philosopher1234 5y ago
  >But you should keep things wide and shallow. No matter what technology you use. This is literally the exact opposite of what I believe, and the bane of my existence at work. Wide and shallow code is spaghetti. Too many APIs = continuous confusion and relearning.
- Thaxll 5y ago
  1. In most web server you have a panic middleware that does exactly that. By default in Go uncaught panic go to stdout.
- nineplay 5y ago
  These are great designs that have been completely ignored by developers in every large scale codebase I've ever worked on. "That's the developers fault, not the languages" Look, the old grey mares of the programming world are doing the best they can. I'm not going to blame C because its developers usually make it up as they go. But we've learned things over the past 50 years, and one of the things we've learned is that company defined 'best practices' and code reviews can not catch all the mistakes that developers make and all of the things that can bring a service to its knees. Go has the benefit of experience. It knows what mistakes developers make and it is going to prevent them from doing that. There is Right Way To Handle Errors in Go. How many times have I seen uncaught exceptions? I saw one a week ago. How many times have I lost resources because I didn't realize something I was calling could throw exceptions? Dozens. Null/Nil exceptions. I couldn't count the null pointer errors I've had to fix in my time. Probably in the hundreds. "should" keep things wide and shallow - somehow when Java 8 came out all the Lambda programmers lost this message. None of these practices scale. We know that because we've seen it
nkozyra 5y ago
> Return err, always as the last parameter Well unfortunately, not always.
- nineplay 5y ago
  If you have a good linter it will flag code where err is not last
kbd 5y ago
> No 'oops I forgot to put in a try/catch and now my code died with no explanation'. This is so backwards. First, I want my program to immediately crash if I have a bug. Go is like shell in that it keeps going even if there's an error. Second, I'm used to getting stack traces, Go is the language that will give "no explanation" by comparison if there's a failure.
- nineplay 5y ago
  I don't know what scale of projects you've worked on. When you're dealing 100K requests/second you very much do not want to immediately crash. It is absolutely the worst think your code can do.
  - kaba0 5y ago
    What framework, language crashes due to an exception, regardless of scale? That exception gets mapped to a http status code and that gets returned.
- grey-area 5y ago
  Your users typically don't want the program to crash, spare a thought for them. Re stack traces, they're fine I guess, but I prefer a well-crafted error message to 200 lines of irrelevant file locations/functions.
  - JoeyJoJoJr 5y ago
    I want my program to crash obviously during development so that I know of the existence of bugs, which can be ironed out before getting to production.
    - grey-area 5y ago
      That's the theory. In practice it's impossible to exercise all the inputs your programs may get, and then they crash in production when users do things you don't expect.
the_gipsy 5y ago
Go errors are better than exceptions, yes, but way worse than Result<T,E>. There are too many ways too screw up error vars + nils + control flows.
latchkey 5y ago
There is no catch for array (or slice) index out of bounds. You either code it in yourself or the best you can do is watch for `recover()` and log it. I wish that one use case was handled better. It is just too easy to mess up.

AtNightWeCode 5y ago

1. You have something that catches and logs all uncaught exceptions. 2. Defer is nice. As easy to forget as using in C#. 3. Always null/nil. Uncle Bob is plain wrong here. 4. Stack trace. But you should keep things wide and shallow. No matter what technology you use. In Go it is about as easy to swallow errors as with try-catch. But my post was more about how all the if-statements generates more unnecessary if-statements.

ssteel 5y ago
The if-statements are not unnecessary if you want to handle errors in place and make the code highly readable. Just because you don't like it doesn't make it wrong.
philosopher1234 5y ago
>But you should keep things wide and shallow. No matter what technology you use. This is literally the exact opposite of what I believe, and the bane of my existence at work. Wide and shallow code is spaghetti. Too many APIs = continuous confusion and relearning.
Thaxll 5y ago
1. In most web server you have a panic middleware that does exactly that. By default in Go uncaught panic go to stdout.
nineplay 5y ago
These are great designs that have been completely ignored by developers in every large scale codebase I've ever worked on. "That's the developers fault, not the languages" Look, the old grey mares of the programming world are doing the best they can. I'm not going to blame C because its developers usually make it up as they go. But we've learned things over the past 50 years, and one of the things we've learned is that company defined 'best practices' and code reviews can not catch all the mistakes that developers make and all of the things that can bring a service to its knees. Go has the benefit of experience. It knows what mistakes developers make and it is going to prevent them from doing that. There is Right Way To Handle Errors in Go. How many times have I seen uncaught exceptions? I saw one a week ago. How many times have I lost resources because I didn't realize something I was calling could throw exceptions? Dozens. Null/Nil exceptions. I couldn't count the null pointer errors I've had to fix in my time. Probably in the hundreds. "should" keep things wide and shallow - somehow when Java 8 came out all the Lambda programmers lost this message. None of these practices scale. We know that because we've seen it

nkozyra 5y ago

> Return err, always as the last parameter Well unfortunately, not always.

nineplay 5y ago
If you have a good linter it will flag code where err is not last

kbd 5y ago

> No 'oops I forgot to put in a try/catch and now my code died with no explanation'. This is so backwards. First, I want my program to immediately crash if I have a bug. Go is like shell in that it keeps going even if there's an error. Second, I'm used to getting stack traces, Go is the language that will give "no explanation" by comparison if there's a failure.

nineplay 5y ago
I don't know what scale of projects you've worked on. When you're dealing 100K requests/second you very much do not want to immediately crash. It is absolutely the worst think your code can do.
- kaba0 5y ago
  What framework, language crashes due to an exception, regardless of scale? That exception gets mapped to a http status code and that gets returned.
grey-area 5y ago
Your users typically don't want the program to crash, spare a thought for them. Re stack traces, they're fine I guess, but I prefer a well-crafted error message to 200 lines of irrelevant file locations/functions.
- JoeyJoJoJr 5y ago
  I want my program to crash obviously during development so that I know of the existence of bugs, which can be ironed out before getting to production.
  - grey-area 5y ago
    That's the theory. In practice it's impossible to exercise all the inputs your programs may get, and then they crash in production when users do things you don't expect.

the_gipsy 5y ago

Go errors are better than exceptions, yes, but way worse than Result<T,E>. There are too many ways too screw up error vars + nils + control flows.

latchkey 5y ago

There is no catch for array (or slice) index out of bounds. You either code it in yourself or the best you can do is watch for `recover()` and log it. I wish that one use case was handled better. It is just too easy to mess up.