[kazinator]

Users of languages that have excellent support for first-class functions and exception handling will probably not agree with you, sorry.

Lower-level code often doesn't "know" how to handle a situation when it is not able to complete its job. The executive decision about how to proceed is somewhere higher up.

Returning an error code that has to be propagated through several levels to the appropriate place is blub programming that belongs to the 1960's.

Higher order functions are useful for error handling, but only when coupled with a dynamic control transfer. The low-level routine invokes a callback, which is some closure belonging to a higher level. For this architecture to be useful to its full potential, that closure must be able to make a jump (for example, a jump to the surrounding code in the function where that closure was created, to effectively abort all the frames between that function and the low level where the error occurred).

[nicerobot]

I was _only_ pointing out, through _one_ simple example, the flaw in your conclusion of Go errors being tedious. I was not discussing other languages nor how to incorporate extensive and fluid error handling in Go to be as capable as any in other language. And since you've raised several points that weren't pertinent, it seems you simply want to disagree with me, so i'll end my side of this discussion. Have fun.

[kazinator]

What is the magic pixie dust in Go which makes returned error values not tedious?

(Besides, of course, what I mentioned in the original posting: panic and recover.)

[junke]

Call panic() from the callback ;-)