Consider the following:
Subscription.update({
_id: { $not: subscription._id },
startDate: { $lt: today },
endDate: { $gt: newEndDate }
}, {
$set: { endDate: newEndDate }
}).catch(errorHandler);
This complains that Subscription.update(...).catch
is undefined.
Whereas calling it after a save()
operation on an item works fine:
user.save().catch(errorHandler);
Also note that I am using Bluebird promises:
mongoose.Promise = require('bluebird');
Mongoose version is 4.4.19.
You should use exec()
if you want to get real promise with then
and catch
http://mongoosejs.com/docs/promises.html
I dislike redundancy :(
Why the need for exec? If there is support for .then
without exec, why
not .catch
as well?
On Mon, May 23, 2016, 19:24 Dmitry Kirilyuk [email protected]
wrote:
http://mongoosejs.com/docs/promises.html
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/Automattic/mongoose/issues/4173#issuecomment-220905377
As I see then
implementation is:
Query.prototype.then = function(resolve, reject) {
return this.exec().then(resolve, reject);
};
So we can do the following for catch
:
Query.prototype.catch = function(reject) {
return this.exec().then(null, reject);
};
Maybe there are some reasons why it can't be implemented like this
Yes that would work for me. @vkarpov15 what are your thoughts?
We can in theory, hasn't been a big priority because .catch()
is such a trivial function and such a (relatively) new development.
Well, I think that's maybe more of a personal opinion :)
I don't find it trivial at all, and there are many use cases for me to only use .catch
and not have a .then
, for example when doing some background updating of data which doesn't need to send back a response, but does need error handling in case it goes wrong.
I find it much cleaner to write .catch(doSomething)
than something like .then(null, doSomething)
, as it makes it easier to distinguish and separate success handlers and failure handlers and makes the code easier to read. I find then...catch
pretty much analogous to a try...catch
.
Also, from my usage experience it has been around for quite a while now and most promise libraries implement the method, as well as .finally()
, which in my opinion is also a must have to avoid code duplication in certain circumstances.
If you'd want me to make a PR for this let me know, I'll be happy to look into it.
Yeah that's a good argument. TBH I don't use .catch()
much and never used .finally()
because I just use co for everything these days - why imitate try/catch
semantics with chaining when you can just use try/catch
? If you can put in a PR that would be excellent, I'll bump this up to 4.5 since you're stoked to get this out :)
Thanks, I'll try to look into it this week :)
Most helpful comment
Well, I think that's maybe more of a personal opinion :)
I don't find it trivial at all, and there are many use cases for me to only use
.catch
and not have a.then
, for example when doing some background updating of data which doesn't need to send back a response, but does need error handling in case it goes wrong.I find it much cleaner to write
.catch(doSomething)
than something like.then(null, doSomething)
, as it makes it easier to distinguish and separate success handlers and failure handlers and makes the code easier to read. I findthen...catch
pretty much analogous to atry...catch
.Also, from my usage experience it has been around for quite a while now and most promise libraries implement the method, as well as
.finally()
, which in my opinion is also a must have to avoid code duplication in certain circumstances.If you'd want me to make a PR for this let me know, I'll be happy to look into it.