26 ms·

> Disadvantage 2 – Error Handling I'm by no means a Go expert, but it felt like Go forced consistent error handling. > Another issue is that it’s easy to forg

> Disadvantage 2 – Error Handling I'm by no means a Go expert, but it felt like Go forced consistent error handling. > Another issue is that it’s easy to forget to handle an error by accident Does anyone have specific examples of error scenarios that skip through the cracks? > While this approach works, it’s easy to lose scope of what went wrong to ensure you can provide a meaningful error to your users. The errors package solves this problem by allowing you to add context and a stack trace to your errors. Isn't this effectively just having propagating error Object that you stack context into ? On the one hand, I agree something like this should "be supported by the language" or rather forced especially since Go supposed to be opinionated, but on the other hand I appreciate having flexibility.

foobiekr 4y ago
Error variable shadowing is a big one that occurs in go codebases. Along with the re-use of for loop variables, it is the most common Go footgun. The go language guys could fix both of these easily - force the caller to check error or explicitly drop it (_) optionally if non-null. That would almost completely eliminate the problem. I really like Go - I can pick up pretty much any Go code, from any open source project or any fellow engineer and read it with ease. No context, secret macros, implicits, etc. The code basically is what it appears to be. This is an enormous benefit in most contexts.
- kjksf 4y ago
  There are lints for that, if that's really a big issue for you. I don't want that because I don't want to litter my code with `_ = fmt.Printf()` `Printf()` is a very common function. It returns an error. I don't care about an error from `Printf` and I don't want to make my code more ugly to avoid bugs I'm not writing in the first place. I've been writing Go code since before v1. I really can't recall a case where I wrote a bug because I forgot to handle an error. I get how you can forget something you do once a month. I don't get how you can forget to handle an error in Go when that's something you do every couple of lines of code written.
  - foobiekr 4y ago
    I regularly see both of the problems I mentioned when reviewing imported dependencies. Yes, the linters can help for your own code base, but something that forces correctness into all code is a big advantage over something that your dependencies may or may not bother with. Most people, I admit, do not review their dependencies, but that in and of itself is a problem. Your fmt.Printf issue is trivially addressed by implementing PrintfOrDrop() which wraps that - and if this was the way Go behaved, you can be certain the standard library would add these variants for conciseness.

foobiekr 4y ago

Error variable shadowing is a big one that occurs in go codebases. Along with the re-use of for loop variables, it is the most common Go footgun. The go language guys could fix both of these easily - force the caller to check error or explicitly drop it (_) optionally if non-null. That would almost completely eliminate the problem. I really like Go - I can pick up pretty much any Go code, from any open source project or any fellow engineer and read it with ease. No context, secret macros, implicits, etc. The code basically is what it appears to be. This is an enormous benefit in most contexts.

kjksf 4y ago
There are lints for that, if that's really a big issue for you. I don't want that because I don't want to litter my code with `_ = fmt.Printf()` `Printf()` is a very common function. It returns an error. I don't care about an error from `Printf` and I don't want to make my code more ugly to avoid bugs I'm not writing in the first place. I've been writing Go code since before v1. I really can't recall a case where I wrote a bug because I forgot to handle an error. I get how you can forget something you do once a month. I don't get how you can forget to handle an error in Go when that's something you do every couple of lines of code written.
- foobiekr 4y ago
  I regularly see both of the problems I mentioned when reviewing imported dependencies. Yes, the linters can help for your own code base, but something that forces correctness into all code is a big advantage over something that your dependencies may or may not bother with. Most people, I admit, do not review their dependencies, but that in and of itself is a problem. Your fmt.Printf issue is trivially addressed by implementing PrintfOrDrop() which wraps that - and if this was the way Go behaved, you can be certain the standard library would add these variants for conciseness.