4 ms·

I really appreciate the lack of magic in go's error handling. I do not appreciate the specific implementation of errors in go. It's inefficient (`reflect` is al

by sidlls 3y ago

I really appreciate the lack of magic in go's error handling. I do not appreciate the specific implementation of errors in go. It's inefficient (`reflect` is all over the place) and prone to obscuring the actual "error path". In applications of non-trivial size, it also becomes an obstacle to implementing structured logging and other components of observability. This makes debugging/triage of, say, a production incident harder than it needs to be.

Thaxll 3y ago
I've never seen or used reflection with error handling in Go, what do you mean?
- sidlls 3y ago
  https://cs.opensource.google/go/go/+/refs/tags/go1.21.6:src/errors/wrap.go;l=17 https://cs.opensource.google/go/go/+/refs/tags/go1.21.6:src/...
  - Thaxll 3y ago
    But this is a detail of implementation, user code does not use reflection with errors.
    - sidlls 3y ago
      That "detail of implementation" is what is used by user code, e.g., `myError.As(...)` uses reflection, implicitly.
      - Thaxll 3y ago
        Then what? It has 0 performance impact, we're talking about error handling here, it's rare and not in hot path.
        sidlls 3y ago
        It does not have 0 performance impact, it's not rare, and in applications that are in the hot path, error handling is also in the hot path.
        Thaxll 3y ago
        No, it only executes when you enter the err != nil block so it's almost never called, again 0 impact on performance.
  - derekperkins 3y ago
    I wouldn't classify type assertion as reflection. It's a super fast type check of the object header, not dynamic reflection.
kbar13 3y ago
in 8 years of writing go at scale i've never used reflection in production code. gonna need an example of what you mean.
- deleted 3y ago
  [deleted]