Does Node support filtered errors like Bluebird?

   somePromise.then(function() {
       return a.b.c.d();
   }).catch(TypeError, ReferenceError, function(e) {
       //Will end up here on programmer error
   }).catch(NetworkError, TimeoutError, function(e) {
       //Will end up here on expected everyday network errors
   }).catch(function(e) {
       //Catch any unexpected errors
   });

It's super useful.

Looks really clean. Does bluebird handle this(https://hackage.haskell.org/package/base-4.9.0.0/docs/Contro...) problem?

    Sometimes you want to catch two different sorts of exception. You could do something like

    f = expr `catch` \ (ex :: ArithException) -> handleArith ex
             `catch` \ (ex :: IOException)    -> handleIO    ex

    However, there are a couple of problems with this approach. The first is that having two exception handlers is
    inefficient. However, the more serious issue is that the second exception handler will catch exceptions in the
    first, e.g.  in the example above, if handleArith throws an IOException then the second exception handler will 
    catch it. 
    Instead, we provide a function catches, which would be used thus:

    f = expr `catches` [Handler (\ex :: ArithException -> handleArith ex),
                        Handler (\ex :: IOException    -> handleIO    ex)]

Yes.

  .catch(ArithException, IOException, handleError)

Edit: Nevermind, I think what you want to be able to do is provide two different error handlers, but essentially catch them at the same time so that if you throw inside one of them, the second one wouldn't catch it.

Not related to the aforementioned Bluebird feature, but I think that's the very reason the promise spec allows you to specify an error callback as the second argument to .then. I guess you can always fallback to an if/switch statement if it's a concern (which is what you'd do with await and try/catch).

this library does: https://github.com/bigeasy/cadence

The standard way to handle errors coming from 'await' is try/catch, and any errors can be handled in the catch block as if they were coming from a synchronous context. So, you'd now filter async errors the same way you filter synchronous ones.

I have not tried, but I would guess no. Why not give it a try and see?

I constantly use `.map` and `.reduce` out of bluebird. I'm not sure I will replace these soon, since it's out of the Promise A+ specs.

As a matter of fact, does anyone have a benchmark of the new nodejs 8's promise implementation against bluebird, because I so far bluebird was faster than the native implementation.

If I remember correctly there is a 4.5x speed up in the bundled V8 (chrome engine) implementation, making it on-par speed-wise with bluebird, however that is hardly your bottleneck anyway.

Just ran it: https://gist.github.com/llambda/aa44d2d44b8356e02f12493ee6e6...

It's not entirely clear how to interpret that; can you provide a summary?

The short story is that native promises are faster now except for the "promisification" part.

The benchmark was designed for realistic use in a node environment, where most of the libraries come callback based. Because of that a very fast "promisify" is really important. Native promises don't provide one so the naive implementation using standards-compatible API is quite slow.

Bluebird's promisify is a lot faster since it relies on non-standard (as in non-ES6-standard) internals instead of using the promise constructor as an ES6-based promisifier would need to do.

edit: on second thought, I haven't looked at the included `util.promisify` - it could be taking advantage of non-public internal V8 promise APIs.