[feffe]

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.

[pg_1234]

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.

[feffe]

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)

[OldHand2018]

> 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.