4 ms·
> needing to use fmt.Errorf to JOIN errors if you want custom string formatting You don't need to, you can implement Unwrap yourself and format the error howev
by morelisp 4y ago
> needing to use fmt.Errorf to JOIN errors if you want custom string formatting
You don't need to, you can implement Unwrap yourself and format the error however you want, just like singular errors today.
> unexpected for fmt to be doing error biz like that.
IIRC, this has to do with avoid circular package dependencies. fmt can depend on errors (and quite a lot of other stuff) but errors can't depend on fmt, so either a) errors needs to implement its own format string processing, b) a wholly new errfmt package is introduced, c) fmt.Errorf.
- Rapzid 4y ago> You don't need to, you can implement Unwrap yourself and format the error however you want, just like singular errors today. Sure, but when discussing the language stdlib design being able to reimplement myself isn't particularly germane. It's what is provided that's being criticized. > IIRC, this has to do with avoid circular package.. The journey to the bad design is interesting, but here we are haha. IMHO it's weird (poor design) to have fmt as the place to join errors if we want to customize the string. The article tries to make the case that errors ARE just strings, but I don't buy what it's selling. The type checks in Is and interface casting in Unwrap are my counter arguments.