1 pointby MarwanAlsoltany3 hours ago1 comment
  • MarwanAlsoltany3 hours ago
    My take on the current state of error handling in Go:

    Most libraries either stay too close to stdlib (and don't solve the real problems) or go full framework mode (and you end up fighting the abstraction). The middle ground is weirdly empty.

    The things I kept running into: - Flat sentinels that can't express parent-child relationships, so every errors.Is check has to enumerate variants manually. - fmt.Errorf wrapping that loses all structure the moment it leaves the package. - No standard place for context that shouldn't be in the message string. - No slog story without boilerplate.

    This is one answer to all four. No globals, no mandatory stack traces, no hidden magic. Just a domain with a label, a formatting pipeline, and errors that are actually inspectable. Stays fully compatible with errors.Is, errors.As, and errors.Unwrap.

    The README is a good read even if the library isn't for you, it goes into why each problem is a problem before showing how it is solved.

    Interested in what people push back on more than whether they like it.