Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Do you really want to handle error conditions in a resumey way far further up the stack?

"Way far" is relative and depends on a number of factor. And I don't consider half a dozen stack frames "way far", it's very easy to attain when using a coding style emphasizing small short methods which call one another.

You also have no bloody idea how the library works internally.

> I'd expect most cases are either handle the error close to the cause

Again, "close" and "far" is relative. I want to handle the error at the closest point to its triggering, but I'm also limited by the data available to know how to handle it. One pushes the handler down the stack, the other up.

> The condition handling approach just seems too magic to me.

There's nothing magic to it.

> It seems to mean the "inner" code calls another method defined somewhere else - but that "somewhere else" is defined by the call stack

Welcome to dynamic scoping, there are cases where it's useful.

> something that's not really very visible in the code.

How is "I'm signaling a condition" not very visible in the code? It says right there that it signals a condition.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: