4 ms·
(1) is entirely debatable. imho your prescription is bad advice. it is very helpful to have []uint call stack pointers (i.e. not a ton of data) associated with
by bigdubs 9y ago
(1) is entirely debatable. imho your prescription is bad advice. it is very helpful to have []uint call stack pointers (i.e. not a ton of data) associated with errors for the 1 in 10 chance you'll need that information, especially when dealing with libraries you don't control that generate errors (which for most programs is the majority, things like lib/pq etc.)
- andrewstuart2 9y agoIn Go, errors are just values, and `error` is just an interface. If some data (e.g. stack traces) is helpful to you then make it part of your error implementation. I'm not entirely opposed to Dave Cheney's errors package but in general I think it's trying to be too clever and novel. If anybody wants to unwrap the errors you return, they have to basically buy into that package and its ecosystem. It's strongly coupled to itself, and that's a bad design choice IMO. We've been fine-tuning error logging and handling for decades. We ought not reinvent the wheel solely because new language constructs are available. My opinion is that structured data and not "errors with behaviors" wins every time, especially when you're building distributed systems and you are going to need to slice/dice your logs when you investigate problems.
- fidget 9y agoIt's not strongly coupled beyond requiring that the wrapper implement a `Cause() error` method. I don't really think that could ever be considered strong coupling
- bigdubs 9y agothey don't have to buy into anything, you just do a `fmt.Printf("%+v", err)` when you want to show stack traces