5 ms·
people who aren't used to actually handling their errors get annoyed at typing return err all the time. They'd prefer an easier way to not bother dealing with
by ikiris 3y ago
people who aren't used to actually handling their errors get annoyed at typing return err all the time.
They'd prefer an easier way to not bother dealing with them with them without outright ignoring them via _
- alpaca128 3y agoI'd get annoyed too, because I know there are much simpler alternatives. Language design should encourage doing things right by making it more convenient than the shortcuts. In Rust that entire check can be a single "?" symbol. How much syntactic sugar is too much is a matter of preference, but I personally think that properly handling all errors without syntactic sugar turns into an unreadable mess because there's just a lot of things which could go wrong.
- bsaul 3y agoalmost 50% of the time i want to add some debugging info to the error before forwarding it one layer above, to provide more context. I think just forwarding all low-level errors is a really bad habit, and go forces you to at least think about this.
- alpaca128 3y 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 3y ago[deleted]
- bsaul 3y 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 3y agoor usually just try again with backoff.
- ikiris 3y agojust returning the error isn't handling it.
- alpaca128 3y agoI never said it is, but to handle an error you have to pass it to the caller that can actually do something with it, whether it's trying alternatives, repeating the step, just logging it, or whatever else - a lot of functions just need to pass it on a couple of times and making this verbose in every single case doesn't make sense to me.