3 ms·
It’s the same paradigm. You still have to do if err != nil. Multierrors have been in the community forever. It’s just been added to the standard library is all.
by earthboundkid 4y ago
It’s the same paradigm. You still have to do if err != nil. Multierrors have been in the community forever. It’s just been added to the standard library is all.
- deleted 4y ago[deleted]
- Groxx 4y agoWell. Kinda. Except that now if someone does `errors.Join` and they pass it to existing code that was using `errors.Unwrap` to inspect an error chain... ... they now get a not-unwrap-able error. Which they can still `As` to inspect... ...but since it's a tree, they can't recursively-`As` to find all instances of a type of error in a chain, like they could before (if you find something in one branch, you can only traverse that branch, because As doesn't maintain iteration-state). It's not an unambiguous win, sadly. New code interacting with old code might misbehave.
- earthboundkid 4y agoWhy would the other code be manually unwrapping and then doing an As test instead of using errors.As? That's extremely Hyram's Law behavior. :-) I agree though that if you have an error log reporting system it should be updated to understand the new multierrors. OTOH, if it's not, it will just see the multierrors as a single node and work fine otherwise.
- Groxx 4y agoAnything trying to display the whole chain is one example, like some every logging library or custom output in existence. For behavior: sometimes wrapping order matters, and As is convoluted to use to determine that, to say the least. Manually unwrapping is easy, and reasonably safe and easy - the standard library does it! But...