Hacker News Reader

Hacker News

Comment by dullgiulio | Hacker News Reader

Parent Full thread

dullgiulio

Please no. I am still fighting the battle of adding contextual information to the error using fmt.Errorf.

I am tired of seeing

SocketException: hostname.com

as full error message.

View on HN

This, errors that are bubbled up should have some context added to them. Otherwise every error ends up being totally meaningless.

I repeatedly fail to understand why golang proponents insist on flogging themselves into becoming human stacktrace authors. This is a solved problem the computer can do better than you, automatically, on your behalf.

Certainly any shortcut syntax should not prevent you from adding human-curated context to your errors. But the current situation comes at an enormous cost, and I truly think there's a bit of Stockholm Syndrome going on here.

Not that I agree with how Go handles it, but the computer is not always better at it. It's a tradeoff, a compromise, or a catch-22.

If you use the full stacktrace, you could get 50 frames of irrelevant library code worsening the signal:noise ratio, hiding what the real issue is.

If you write your own context, then when it _is_ a problem with library code, you're hopelessly lost.

I think we need better tooling: the ability to add your own contextual information, to propagate errors explicitly but without boilerplate, and the ability to _choose_ the level of information you see afterward.

We have log viewers that can filter out by severity level, why don't we have a standardization for stack traces to let you filter to what you want?

It's not the same thing. In Java and Python programs, especially Java programs, developers seems to think it's perfectly reasonable to present the end user with a 100 entries stack trace. This may be of use to the developer to debug issues but it's not a substitute for good error messages that are to be presented to the end user.

I don't think Go errors are perfect either as you just tend to concatenate strings together but the information they include are more user friendly if done right, i.e. not just bubble up the error, but adding context that the user is aware of.

Languages that bubble errors up still let you catch and categorize the errors at the top, allowing for very presentable formats for the end user ... in fact, in my experience, because they don't have to deal with tiers of pointless boilerplate, devs put the effort instead into better end user/public errors.

I say this as an ex-(for now)-Python dev, currently suffering though Go's tedious error handling.

I agree that in theory the same is possible in languages that use exceptions but in my experience laziness often wins out. The exception is caught on the level where it's suitable to terminate the stack unwinding and deal with the error from the applications point of view. At that point it's too late to add user recognizable context to the error that what Go advocates by its design.

My opinion is that a syntax shortcut such as "?" to just bubble up errors without adding context would still be useful. I would welcome it. There are cases where I find that no additional context is needed. I think the Go designers are afraid what it would lead to though (the laziness wins out hypothesis)

> especially Java programs, developers seems to think it's perfectly reasonable to present the end user with a 100 entries stack trace

Try debugging something in Spark/DataBricks. It is so incredibly tedious; stack traces can easily reach 200 lines or more.

> I truly think there's a bit of Stockholm Syndrome going on here.

I agree in sense Stockholm Syndrome going on but not just for Go but with almost every technology including Go.

When we have folks defending Rust slow builds, Swift breaking changes, Half-assed tooling for Scala, poor power management on linux laptops and on and on. It could mean either plain old stockholm syndrome or that people can work around these minor irritants and get main benefit of technology. Just like with anything else in life.

Attributing this to stockholm syndrome is a bit convenient and reductionist.

Stacktraces are better than just bubbling up, and yes a mechanism to minimize if-err could also allow for human annotations.

I'd love if Go had a stronger type system, but I know it'd probably come with longer compile times like Rust has. I think it's not a dogmatic take, and I think a lot of golang proponent do take the same nuanced position.

just use pkg/errors? it includes the stack trace. there wasn't a need to include this in the stdlib thats all.

It can be done well, see Zig's traces [0].

[0] https://ziglang.org/documentation/master/#Error-Return-Trace...

I don't see how those are mutually exclusive. You could do something like:

  x, err := f(); if err != nil return fmt.Errorf("More context -> %s", err)

(I'm not attached to that specific syntax, it's just an example of a hypothetical one-liner)

Reply on news.ycombinator.com