4 ms·

Something about needing to use fmt.Errorf to JOIN errors if you want custom string formatting rubs me the wrong way. I had to read that section twice because it

by Rapzid 4y ago

Something about needing to use fmt.Errorf to JOIN errors if you want custom string formatting rubs me the wrong way. I had to read that section twice because it completely went over my head it acting as a join.. So unexpected for fmt to be doing error biz like that.

leetrout 4y ago
Especially given the current landscape of log handling as the author points out. I am all in on structured logging most of the time and I don't want to have to deal with a newline causing multiple records in my log aggregation.
- Rapzid 4y ago
  It's also not true the interface for Unwrap() doesn't exist; behold https://cs.opensource.google/go/go/+/refs/tags/go1.19.4:src/errors/wrap.go;l=14 https://cs.opensource.google/go/go/+/refs/tags/go1.19.4:src/... ... Yeah, it's not exported but...
  - lzap 4y ago
    In the blogpost I specifically wrote "There is no (named) interface in the standard library..." because I was aware of the function you point out. Rather than unexported interface, I would probably call that an "anonymous interface". Anyway, now that I read that, I should probably skip this fact and just keep the example interface. It is not uncommon practice in Go to make "copies" of interfaces to avoid extra dependency (or cyclic dependency).
    - Rapzid 4y ago
      Sorry, that shot right past me. The article sounded, to me anyway, impressed the interface didn't exist. Seeing the cast/check against the anonymous interface left me unimpressed haha. > It is not uncommon practice in Go to make "copies" of interfaces to avoid extra dependency (or cyclic dependency). I hadn't really noticed but my exposure to the source is spotty. See what they are doing there and can imagine why, it just irks me. There are now implicit, "standard" shapes for Error that don't have named, exported interfaces and presumably anyone wanting to write code around both Unwrap shapes will need to reach for the same techniques to suss out what they are dealing with..
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.

by Rapzid 4y ago

leetrout 4y ago

Especially given the current landscape of log handling as the author points out. I am all in on structured logging most of the time and I don't want to have to deal with a newline causing multiple records in my log aggregation.

Rapzid 4y ago
It's also not true the interface for Unwrap() doesn't exist; behold https://cs.opensource.google/go/go/+/refs/tags/go1.19.4:src/errors/wrap.go;l=14 https://cs.opensource.google/go/go/+/refs/tags/go1.19.4:src/... ... Yeah, it's not exported but...
- lzap 4y ago
  In the blogpost I specifically wrote "There is no (named) interface in the standard library..." because I was aware of the function you point out. Rather than unexported interface, I would probably call that an "anonymous interface". Anyway, now that I read that, I should probably skip this fact and just keep the example interface. It is not uncommon practice in Go to make "copies" of interfaces to avoid extra dependency (or cyclic dependency).
  - Rapzid 4y ago
    Sorry, that shot right past me. The article sounded, to me anyway, impressed the interface didn't exist. Seeing the cast/check against the anonymous interface left me unimpressed haha. > It is not uncommon practice in Go to make "copies" of interfaces to avoid extra dependency (or cyclic dependency). I hadn't really noticed but my exposure to the source is spotty. See what they are doing there and can imagine why, it just irks me. There are now implicit, "standard" shapes for Error that don't have named, exported interfaces and presumably anyone wanting to write code around both Unwrap shapes will need to reach for the same techniques to suss out what they are dealing with..

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.