HelloSugoi | Intermediate — Senior | Full Stack | Devops | Solidity | nodejs / node | Ethereum | Los Angeles | REMOTE | www.hellosugoi.com
We are event ticketing platform with high dreams of eating the entire event management ecosystem. Want to eliminate ticketing fraud? Want to create an equitable platform for event organizers, promoters, artists, vendors, venues, and fans? Then Join us and build it with us!
We are looking for full stack engineers and Solidity Developers. Don’t know Solidity? That's coolio, we will tech you. :)
Providing a user with a list of recently or relevant tickets being sold is cool. But Manually adding them to a user list does not help the customer. Especially if they mark them as sold after being "available".
HelloSugoi | Junior — Senior | Full Stack | Devops | Solidity | nodejs / node | Ethereum | Los Angeles | REMOTE | www.hellosugoi.com
We are event ticketing platform with high dreams of eating the entire event management ecosystem. Want to eliminate ticketing fraud? Want to create an equitable platform for event organizers, promoters, artists, vendors, venues, and fans? Then Join us and build it with us!
We are looking for full stack engineers and Solidity Developers. Don’t know Solidity? That's coolio, we will tech you. :)
What is nice is that it eats into bluebird. I love bluebird, and there are some nice utility functions. But if you only used it to promisify or create promises, there may be no need to keep it.
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
});
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)]
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).
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 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.
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.
