5 ms·

I wish that an unhandled error would crash its way up the stack automatically returning error if the next function up can do so, until it is either caught into

I wish that an unhandled error would crash its way up the stack automatically returning error if the next function up can do so, until it is either caught into a variable or can't be returned (panic if error can't be returned). This would get close to python try/catch with even lighter syntax. This would cut so much boilerplate hand carrying error up the stack.

38 2y ago
[flagged]
assbuttbuttass 2y ago
panic() already exists
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 ago
  This 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 ago
    I 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.
Neikius 2y ago
The thing that bothers me is... golang actually has exceptions. It is just that nobody will dare mention it. Panic and recover eh? It is just that by default error is the thing you should use and everything and everyone does. Then the exception mechanism comes along and you now have 2 ways of handling errors. Making things quite confusing.

38 2y ago

[flagged]

assbuttbuttass 2y ago

panic() already exists

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 ago
This 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 ago
  I 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.

Neikius 2y ago

The thing that bothers me is... golang actually has exceptions. It is just that nobody will dare mention it. Panic and recover eh? It is just that by default error is the thing you should use and everything and everyone does. Then the exception mechanism comes along and you now have 2 ways of handling errors. Making things quite confusing.