[jerf]

I don't think you can do that with Javascript or Node.js. When you have a callback, you lose all stack above it.

See, I wouldn't even call that "evented code" in the way that people are using the term, regardless of what it says on the tin, precisely because you aren't losing the stack frame here and can still catch exceptions and such. Evented to my mind is something like Node.js is when you have to chop up your code manually. At least, I've never seen anybody demo Node.js code that isn't chopped up manually and I am at a loss as to what features of Javascript would let you translate that Ruby snippet directly without losing something fundamental about the stack.

Under the hood, everything's event-based (with optional preemptive multitasking), there's just varying levels of compiler optimization that affects how much you have to do manually and how much you have to worry about it. The inner event loop of Erlang and the inner event loop of Node.js and in fact the inner event loop of just about anything nowadays looks pretty much the same.

That's not the way in which I say evented code blows up. If you can write like that, it doesn't blow up, because you don't have to sit there and basically manually implement your own stack handling if you want anything like that sort sane exception handling, it all just works.

Since this is a terminology issue there is, as always, grey areas, but since I mostly use the term evented in the context of the Node.js hype I tend to use it that way. I've been doing stuff like your snippet for a while too and it hasn't blown up on me either, which is why I'm so down on the style of coding Node.js entails, which does.

The point of my snippet is not that that is a brilliant choice intrinsically, the point is that you don't have the choice and end up implementing anything like that manually.

[tptacek]

You've lost me. Nothing in this code depends on having a single consistent stack from main() to handle_next_request().

[jerf]

You need a "consistent" stack in the whole of everything executing under "handle_request" if you want that "one single exception handler bracketing the entire request". You don't get that in Javascript; you need a language with more power. There are several viable options: Threading, continuations, some hacked up thing like Python's yield (which is neat, but limited). But something.

Javascript's a very nice, dynamic language in most ways but its functions are very, very weak. They'll get better in the next version of ECMAScript, though. (Node.js will probably benefit from it.)

[tptacek]

I'm pretty sure you're wrong about this. The exact same idiom I used to buffer up requests and feed them whole to a single function that could catch all possible exceptions works just fine in Javascript. Is this an issue with JS exceptions that I'm unaware of? I may just be talking past you.

[jerf]

You're talking about the function of what I posted, I'm talking about the form.

    try:
        something = some_io_that_needs_an_event_callback()
        if do_something_with(something):
            more_io_with_callback()
            some_other_callback_thingy()
        else:
            yet_other_io()
            some_other_io()
    except AnyException:
        do_something_sane()

is not a structure available to you in Node.js, again, pending somebody proving otherwise in Javascript (though I've made this complaint in other places where somebody really should have shown me the code). That expands to tons of code in Javascript, code which is very resistant to abstraction.

Your code block says it is available to you in Ruby. There's no reason why it shouldn't be; it's not a hard compiler transform to manage that. Taking code that looks like a "thread" but compiling it into events and using something-like-continuations to keep the stack together is on the order of a homework problem. Based on what I know about Ruby, the responsibility of those pieces is split up differently but all the pieces must be there. But it's not something Javascript can do (quite yet, and based on what I've seen in Python the 'yield' approach has its own issues).