4 ms·

The real problem with callbacks is error handling. Using anonymous functions doesn't address this problem. The .then notation has the same problem. The await s

by chmike 13y ago

The real problem with callbacks is error handling. Using anonymous functions doesn't address this problem. The .then notation has the same problem. The await solution (or any equivalent) has the benefit to present the call as a synchronous call which is trivial to read and understand. It also has the benefit to support all existing and proven error handling methods. try catch, etc. This is the best solution to asynchronous calls that I have seen so far. I'm currently using c++ asio, and it's a nightmare.

lucian1900 13y ago
Promises are actually pretty good at error handling, the first error encountered is returned.
- Nitramp 13y ago
  Well, Q allows you to attach an error handler with catch: bla(). then(something). then(someOther). catch(ohNoes); First, this gives you really bad stack traces, essentially you have no chance to figure out what happened before your error handler got called. You can get slightly less bizarre stack traces with `Q.longStackSupport = true;`, but that has a serious performance impact (creating a new throwable per invocation). Second, if you try to get better code structure by breaking up your program into named functions ('something', 'someOther' above), you loose locality, i.e. your error handler does not share a scope with its causing code. You can fix that by passing the entire promise to a processing function, but this again obscures things. Compared to a program that just does: x := bla(); var y; try { y = something(x); } catch(...) { ... } return someOther(y); The promise code is still a lot more complicated. I agree with Miguel de Icaza, continuation passing style/callbacks do destroy 'natural' program structure, and make it much harder to use the regular programming language's idioms (loops, returns, ...). I'd be hugely in favour of go's approach with very cheap goroutines, so you don't actually have to use CPS just because your runtime isn't clever enough to use more than one thread (ahem node). OTOH go's lack of exceptions kills the whole argument by bringing back the error handling of the 80s :-(

by chmike 13y ago

lucian1900 13y ago

Promises are actually pretty good at error handling, the first error encountered is returned.

Nitramp 13y ago
Well, Q allows you to attach an error handler with catch: bla(). then(something). then(someOther). catch(ohNoes); First, this gives you really bad stack traces, essentially you have no chance to figure out what happened before your error handler got called. You can get slightly less bizarre stack traces with `Q.longStackSupport = true;`, but that has a serious performance impact (creating a new throwable per invocation). Second, if you try to get better code structure by breaking up your program into named functions ('something', 'someOther' above), you loose locality, i.e. your error handler does not share a scope with its causing code. You can fix that by passing the entire promise to a processing function, but this again obscures things. Compared to a program that just does: x := bla(); var y; try { y = something(x); } catch(...) { ... } return someOther(y); The promise code is still a lot more complicated. I agree with Miguel de Icaza, continuation passing style/callbacks do destroy 'natural' program structure, and make it much harder to use the regular programming language's idioms (loops, returns, ...). I'd be hugely in favour of go's approach with very cheap goroutines, so you don't actually have to use CPS just because your runtime isn't clever enough to use more than one thread (ahem node). OTOH go's lack of exceptions kills the whole argument by bringing back the error handling of the 80s :-(