3 ms·
I talked in my previous post (https://kokada.capivaras.dev/blog/go-a-reasonable-good-language/ https://kokada.capivaras.dev/blog/go-a-reasonable-good-langu...)
by kokada 2y ago
I talked in my previous post (https://kokada.capivaras.dev/blog/go-a-reasonable-good-language/ https://kokada.capivaras.dev/blog/go-a-reasonable-good-langu...) that nowadays I just implement a generic `must*()` family of functions that can be used as:
func must(err error) {
if err != nil {
panic(err)
}
}
func must1[T any](v T, err error) T {
must(err)
return v
}
func maybeError() (bool, error) { ... }
result := must1(maybeError())
And this generally works fine 99% of the time when I just want a stack trace on error.
So this is why I don't care that much about having a syntax sugar for this operation anymore in Go.
- daghamm 2y agoThis is not error-handling :) In fact, this is the opposite of error handling. In any serious application this might be worse than ignoring errors
- kokada 2y agoI didn't say this is error handling, this is a stack trace for debugging on error. Similar to an uncaught exception in other languages. And yes, I will not use this on production applications or libraries, I mostly use this in scripts where this kind of thing makes sense.