Thread 105909822

if err != nil {
return fmt.Errorf("oopsie wopsie: %w", err);
}

laugh niggers

>>105909822 (OP)
yes.jpg

>>105909822 (OP)
Golang error handling is verbose but it makes perfect sense.

>>105910560
type based errors are great in languages with real type systems (i.e. not go)

>>105910583
chat is this true

>>105910583
I tested out making a go-like language with algebraic types for errors to test this theory and gave up on it and went back to the way go does it, just with a new control flow statement that makes the if statement in the OP along with some others into a one-liner. You basically have to have full monadic errors like haskell, or multi-return like go, anything in between just sucks to use.

>>105910560
>manually writing exception machinery makes perfect sense

>>105911426
It is slightly pedantic but also elegant and completely unambiguous.
You have panic and recover if you need them. In most cases you do not though.

>>105909822 (OP)
>doesn't realize Go's error handling handling via tuples of (T, error) are somewhat equivalent to a simplified T | error, where err != nil is equivalent to matching the error branch

When you move back to langs that let you transparently bubble up the error, you end up missing Go's error handling in that by default it forces you to explicitly decide at the call site if to ignore the error or handle it (wrap and bubble it, log it, etc).

>>105911900
why do you return generic error if you need to branch on it?

people always reiterate same nonsense about "error handling" without stopping and thinking for a second what's the use case.

>>105909822 (OP)
Yes and it just works, do you need more?

errors are for humans to fix bugs
they also allow to fail gracefully without restarting software, in that case the origin of error isn't important (but can be useful to display error message to user, for example)

>>105911666
in other words, it's optimizing for the rare case you need to do something different at the expense of the common case where you just pass the error along
>i'm wearing my gum boots every day to be prepared for the next flood

>>105911987
>errors are for humans to fix bugs
lolno you retard
they are for externally caused errors, not bugs

exceptions were mistake and I'm tired of pretending they are not

>>105912336
You should be, almost without exception, annotating your fucking errors. Otherwise it's incredibly obnoxious to stack trace a failure through a complicated API. Put relevant context in your errors, dipshit.

>>105913525
>exceptions were mistake and I'm tired of
The program exited unexpectedly. (Error code 69)

>>105913742
Great, error code 69 isn't new to me, I immediately know what's wrong instead of having to grep through 5000 line exception traceback

>>105913574
you'll end up with 100 nested errors going "failed to do x: failed to do why: failed to do z: ..."
there's no need to add context in every function

package baseline

func Based (b based) {
if based != nil {
log.Println("based beyond belief")
}
}


package main

func main(){
x, b := operation.One()
baseline.Based(b)
println(x)
}