Mongoose: Model.update(...).catch is undefined

Created on 22 May 2016  Â·  8Comments  Â·  Source: Automattic/mongoose

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.

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 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.

All 8 comments

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 :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

weisjohn picture weisjohn  Â·  3Comments

ghost picture ghost  Â·  3Comments

gustavomanolo picture gustavomanolo  Â·  3Comments

lukasz-zak picture lukasz-zak  Â·  3Comments

CodeurSauvage picture CodeurSauvage  Â·  3Comments