3 ms·
As a Node.js dev: don't hold your breath waiting for better exception support in callback-based asynchronous code. Node didn't really have a procedural legacy;
by zbentley 9y ago
As a Node.js dev: don't hold your breath waiting for better exception support in callback-based asynchronous code. Node didn't really have a procedural legacy; it was always async (sorta), and exceptions are awful to try to reason about with callbacks. Then we got Promises, which made it worse. Now we have async/await, which helps restore typical exception behavior a bit . . . until you have to integrate with any code written in a callback- or promise-oriented style (anything older than 15 months, almost all of the standard library).
In general, I think without language-level support for continuations (callbacks, coroutines, promises, async-"colored" functions, whatever), projects like Vert.x are going to cause a lot of friction with regards to exceptions. Having a large synchronous legacy to contend with doesn't help either.
- thenewwazoo 9y agoI don't mean this to be flippant: there's a Javascript standard library?
- minus7 9y agoActually it can work quite well without language-level support. Python's gevent library [0] shows that. It "simply" monkey-patches the standard library's IO functions to implicitly switch to another "greenlet" when blocking IO is performed. On the user side you don't really see anything of that (no "await" or similar). Admittedly, that hides possible points of context switches, but is still far less dangerous with regard to race conditions than OS threads. Unfortunately, gevent seems to be shunned quite a bit and I haven't seen other languages do similar things. [0] http://www.gevent.org/ http://www.gevent.org/