4 ms·
> I think just forwarding all low-level errors is a really bad habit Why exactly is that a bad habit? In almost all situations where I return an error I alread
by alpaca128 4y ago
> I think just forwarding all low-level errors is a really bad habit
Why exactly is that a bad habit? In almost all situations where I return an error I already have enough context, I'm just wondering what else I'd add to that.
> go forces you to at least think about this
Boilerplate code definitely doesn't incentivize thinking.
- deleted 4y ago[deleted]
- bsaul 4y agomost errors you encounters are with i/o and are stupid "can't read, can't write or can't serialize". In a network environment (which is originally what go was made for) you often need to add tracing information, business-level identifiers or processing information related to your state etc. I'm currently writing a fairly complex api in go, and to be honest this really hasn't bothered me once. Not to say it doesn't exists, but with time i've come very suspicious of people complaints over go. Most of the time those complaints come from people that didn't realize they missed an opportunity to have written a much much more elegant solution to their problem.
- ikiris 4y agoor usually just try again with backoff.