Mongoose обработка ошибок

• Error()
• Error.CastError
• Error.DivergentArrayError
• Error.DocumentNotFoundError
• Error.MissingSchemaError
• Error.MongooseServerSelectionError
• Error.OverwriteModelError
• Error.ParallelSaveError
• Error.StrictModeError
• Error.StrictPopulateError
• Error.ValidationError
• Error.ValidatorError
• Error.VersionError
• Error.messages
• Error.prototype.name

Error()

Parameters:

• msg
  «String» Error message

Type:

• «constructor»

Inherits:

• «Error»

const Model = mongoose.model('Test', new mongoose.Schema({ answer: Number }));
const doc = new Model({ answer: 'not a number' });
const err = doc.validateSync();

err instanceof mongoose.Error.ValidationError; // true

Error.CastError

Type:

• «property»

An instance of this error class will be returned when mongoose failed to
cast a value.

Error.DivergentArrayError

Type:

• «property»

An instance of this error will be returned if you used an array projection
and then modified the array in an unsafe way.

Error.DocumentNotFoundError

Type:

• «property»

An instance of this error class will be returned when save() fails
because the underlying
document was not found. The constructor takes one parameter, the
conditions that mongoose passed to updateOne() when trying to update
the document.

Error.MissingSchemaError

Type:

• «property»

Thrown when you try to access a model that has not been registered yet

Error.MongooseServerSelectionError

Type:

• «property»

Thrown when the MongoDB Node driver can’t connect to a valid server
to send an operation to.

Error.OverwriteModelError

Type:

• «property»

Error.ParallelSaveError

Type:

• «property»

An instance of this error class will be returned when you call save() multiple
times on the same document in parallel. See the FAQ for more
information.

Error.StrictModeError

Type:

• «property»

Thrown when your try to pass values to model constructor that
were not specified in schema or change immutable properties when
strict mode is "throw"

Error.StrictPopulateError

Type:

• «property»

An instance of this error class will be returned when mongoose failed to
populate with a path that is not existing.

Error.ValidationError

Type:

• «property»

An instance of this error class will be returned when validation failed.
The errors property contains an object whose keys are the paths that failed and whose values are
instances of CastError or ValidationError.

Error.ValidatorError

Type:

• «property»

const schema = Schema({ name: { type: String, required: true } });
const Model = mongoose.model('Test', schema);
const doc = new Model({});

// Top-level error is a ValidationError, **not** a ValidatorError
const err = doc.validateSync();
err instanceof mongoose.Error.ValidationError; // true

// A ValidationError `err` has 0 or more ValidatorErrors keyed by the
// path in the `err.errors` property.
err.errors['name'] instanceof mongoose.Error.ValidatorError;

err.errors['name'].kind; // 'required'
err.errors['name'].path; // 'name'
err.errors['name'].value; // undefined

Error.VersionError

Type:

• «property»

An instance of this error class will be returned when you call save() after
the document in the database was changed in a potentially unsafe way. See
the versionKey option for more information.

Error.messages

Type:

• «property»

See:

• Error.messages

The default built-in validator error messages.

Error.prototype.name

Type:

• «String»

I know the validator plugins are probably helpful, but I think the mongoose validation stuff is more intimidating than it really is complicated. It definitely looks complicated from the outside but once you start tearing into it, it’s not so bad.

If you check out the code below, you’ll see an example of how a custom error message can be returned using built-in validators.

All you have to do is set a second parameter, with your own custom error message, when setting up your fields.

Checkout the required and minlength and maxlength fields below to see how I’ve setup a custom error message, and then check out the methods below as to how the error object can be accessed or sent to the front end:

// Grab dependencies:
var mongoose = require('mongoose');

// Setup a schema:
var UserSchema = new mongoose.Schema (
    {
        username: {
            type: String,
            minlength: [2, 'Username must be at least 2 characters.'],
            maxlength: [20, 'Username must be less than 20 characters.'],
            required: [true, 'Your username cannot be blank.'],
            trim: true,
            unique: true,
            dropDups: true,
        }, // end username field
    },
    {
        timestamps: true,
    },
);

// Export the schema:
module.exports = mongoose.model('User', UserSchema);

The above sets up our fields to have custom error messages. But how do we access them or send them to our front end? We could have the following method setup in our server controller, whose response data is sent back to angular:

var myControllerMethods = {
    register : function(req, res) {
        // Create a user based on the schema we created:
        User.create(req.body)
            .then(function(newUser) {
                console.log('New User Created!', newUser);
                res.json(newUser);
            })
            .catch(function(err) {
                if (err.name == 'ValidationError') {
                    console.error('Error Validating!', err);
                    res.status(422).json(err);
                } else {
                    console.error(err);
                    res.status(500).json(err);
                }
            })
    },
};

If you ran the code above, and any of our mongoose validators did not pass, the error (err) object will be grabbed by the .catch() in the promise. If you console log this error, you’ll see in that object is our custom message, depending upon which error got flagged.

Note: The above example is just for adding custom validation messages to the already built-in validations that Mongoose possesses (like required, minlength, maxlength and so forth).

If you want to create more advanced validations, such as validating fields against regex patterns or the like, then you’ll have to create custom validator functions.

See the «Custom Validators» section at this link for a great example of how to add a validator right onto your field: http://mongoosejs.com/docs/validation.html.

Note: You can also use «pre save hooks» and «instance methods», but this is beyond the scope of this question and the built in validators and «Custom Validators» (link aforementioned) are easier routes.

Hope this helps!

Mongoose 4.5.0 introduces the ability to handle errors in middleware. This lets
you write middleware and plugins to transform errors into something useful
for your application. In other words, no more cryptic «E11000 duplicate key» errors will leak to your users if you set up
the correct middleware. If you’ve
used Express’ error handling middleware,
mongoose’s will look familiar.

An Aside On Mongoose Post Middleware

Mongoose has 2 types of middleware, «pre» middleware and «post» middleware.
Pre middleware executes before the wrapped function, and post middleware
executes after the wrapped function.

schema.pre('save', function(next) {
  console.log('before save');
  next();
});

schema.post('save', function(doc) {
  console.log('after save');
});

doc.save(); // Prints 'before save' followed by 'after save'

However, since mongoose 3.x post middleware has been interchangeable with
on() calls. In other words, schema.post('save') is the same thing as
schema.on('save'). Therefore, by design, mongoose document post middleware
does not get flow control
(query post middleware does, and in 5.0 document post middleware will too).

schema.post('save', function() {
  console.log('after save');
});

doc.save(function() {
  // May print "after save" after "save callback" or vice versa,
  // the order is undefined.
  console.log('save callback');
});

Mongoose 4.5 introduces a special type of document post middleware that
does get flow control: error handlers.

Introducing Mongoose Error Handling Middleware

You define an error handler the same way you define a normal post middleware.
To mark a post middleware as an error handler, you need to make it take 3
parameters:

var schema = new Schema({
  name: {
    type: String,
    unique: true
  }
});

// Handler **must** take 3 parameters: the error that occurred, the document
// in question, and the `next()` function
schema.post('save', function(error, doc, next) {
  if (error.name === 'MongoError' && error.code === 11000) {
    next(new Error('There was a duplicate key error'));
  } else {
    next(error);
  }
});

var Person = mongoose.model('Person', schema);

var person = { name: 'Val' };

Person.create([person, person], function(error) {
  // Will print out "There was a duplicate key error"
  console.log(error);
});

An error handler middleware only gets called when an error occurred. In
other words, the above error handler middleware will only execute if a
pre save hook called next() with an error, if save() calls back with
an error, or if a previous post hook called next() with an error.

schema.pre('save', function(next) {
  // This middleware will prevent `save()` from executing and go straight
  // to executing the error handling middleware
  next(new Error('pre save error'));
});

schema.post('save', function(doc, next) {
  // If this hook is defined _before_ an error handler middleware, this will
  // skip all other non-error-handler post save hooks and execute the next
  // error handler middleware
  next(new Error('post save error'));
});

As an aside, there are 4 functions in mongoose that can trigger a
duplicate key error: save(), insertMany(), update(), and
fineOneAndUpdate(). The create() function can also trigger a duplicate
key error, but create() is just a thin wrapper around save(). Here’s how
you can handle duplicate key errors for all these functions:

var schema = new Schema({
  name: {
    type: String,
    unique: true
  }
}, { emitIndexErrors: true });

var handleE11000 = function(error, res, next) {
  if (error.name === 'MongoError' && error.code === 11000) {
    next(new Error('There was a duplicate key error'));
  } else {
    next();
  }
};

schema.post('save', handleE11000);
schema.post('update', handleE11000);
schema.post('findOneAndUpdate', handleE11000);
schema.post('insertMany', handleE11000);

var Person = mongoose.model('Person', schema);

With this new feature, you can write plugins that can convert MongoDB-specific
errors (like the duplicate key error above) as well as mongoose-specific errors
(like validation errors) into something that makes sense for your application.

Moving On

Mongoose error handling middleware gives you a centralized mechanism for
handling errors in your application. You can use error handlers for logging
and even transforming errors, so you can standardize error formatting for your
API. I’m especially excited to see what plugins
you can write using error handling middleware.