hollyhoppet wrote
Reply to comment by twovests in I truly believe that Go is the worst popular modern language. by flabberghaster
You have to explicitly pass and handle your own error stack
this is gross lol
twovests wrote
to be clear i have not done a lot of go and what i have done was mostly a year ago
this is because i did not like go
flabberghaster OP wrote
I think? You can just assign it to _ and it will be ignored, if you want. Like
val, _ := something()
twovests wrote
ya, what i mean is, i think you gotta:
- write
val, err := something()
and useerr
to build your own stack trace - make sure
something()
returns thaterr
in the first place, if you wrote it
otherwise you don't get a stacktrace when something()
fails.
i'm not confident about this, because i can't imagine Go reaching any acclaim while being so hilariously designed. but "Errors are values" so maybe we are right and go is bad
flabberghaster OP wrote
Oh, yeah. That's true. I have so much problems debugging go code because every crash is like, "the program the an unhandled error at like 123" and then you look at like 123 and it's like
if err := some_call() {
panic("some_call failed!");
}
You just hid the stack trace that tells me what went wrong!!!
twovests wrote
I much prefer Every Other Language, where you get a stack trace that runs into the library code!
something like
some_call() failed at call another_call(x, y, z)
another_call(x,y,z) failed at internal_library(x[123])
internal_library.c failed on line 1025: index 123 is out of bounds for array x
flabberghaster OP wrote
You can wrap your errors though, it's not hard to do. Use fmt.Errorf()
but you have to actually do it. And people tend not to where I work.
twovests wrote
Same situation! It's a bit more boilerplate on everything I write, but the main problem is not everyone does it.
Thankfully, now nobody writes Go at my work (^:
Unthankfully, we're language-shy because of it, lol
Viewing a single comment thread. View all comments