5 ms·
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 plai
by 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 agoThe 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 ago1. In most web server you have a panic middleware that does exactly that. By default in Go uncaught panic go to stdout.
- nineplay 5y agoThese 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