3 ms·
> Rust was designed smarter from the start I guess this makes it pretty clear that there's no useful conversation to be had with you on this topic. > (In poin
by kiitos 1y ago
> Rust was designed smarter from the start
I guess this makes it pretty clear that there's no useful conversation to be had with you on this topic.
> (In point of fact you shouldn't use fmt.Errorf if you're serious about errors either; it cannot be usefully inspected at runtime. You want an explicitly declared error type for that.)
You don't need a discrete error type to allow callers to inspect returned errors at runtime -- `fmt.Errorf("annotation: %w", err)` allows callers to check for sentinel errors via `errors.Is` -- which is the overwhelmingly most common case.
- geoka9 1y agoExactly; `return fmt.Errorf("annotation: %w", err)` is just a log-friendlier version of `return err`. The original wrapped error is meant for runtime inspection.
- kiitos 1y agoThe fmt.Errorf expr is wrapping the error, with relevant context at the wrap-site. It's not just "log-friendlier" it's actually important metadata.
- geoka9 1y agoI think we are saying the same thing: it is important metadata which is meant for human consumption (as opposed to the wrapped sentinel error) -- hence "log-friendly".
- kiitos 1y ago> `return fmt.Errorf("annotation: %w", err)` is just a log-friendlier version of `return err` This claim isn't true. The annotation-wrapping isn't just about making the returned error 'log-friendlier', it's annotating the error with context-specific information that's useful beyond "log" contexts. More concretely, that kind of annotation is critical if you expect to be able to introspect runtime errors in any way at all -- it's not a "log-friendlier" version of `return err`, it's an important and necessary change vs. `return err` which is in no way perfunctory or whatever.