В този момент изглежда логично да се съгласим с това как mongoose обработва грешки.
Не бихте искали вашите модели да обработват съобщения за грешки. Слоят за представяне (контролери?) трябва да разчита на type
за да решите кое е най-удобното за потребителя съобщение за показване (и18n се разглежда).
Има и случай, когато валидирането може да се случи чрез използване на междинен софтуер. В този случай съобщението за грешка, което ще се появи на вашия контролер, е това, което предадете на next()
обратно повикване.
Така че, за случая на междинен софтуер, макар и да не е документиран, за да поддържате последователен API за валидиране във вашите модели, трябва директно да използвате конструкторите за грешки на Mongoose:
var mongoose = require('mongoose');
var ValidationError = mongoose.Error.ValidationError;
var ValidatorError = mongoose.Error.ValidatorError;
schema.pre('save', function (next) {
if (/someregex/i.test(this.email)) {
var error = new ValidationError(this);
error.errors.email = new ValidatorError('email', 'Email is not valid', 'notvalid', this.email);
return next(error);
}
next();
});
По този начин ви се гарантира последователна обработка на грешки при валидиране, дори ако грешката при валидиране произлиза от междинен софтуер.
За да съпоставя правилно съобщенията за грешки с типове, бих създал enum която би действала като статична карта за всички възможни типове:
// my controller.js
var ValidationErrors = {
REQUIRED: 'required',
NOTVALID: 'notvalid',
/* ... */
};
app.post('/register', function(req, res){
var user = new userModel.Model(req.body);
user.save(function(err){
if (err) {
var errMessage = '';
// go through all the errors...
for (var errName in err.errors) {
switch(err.errors[errName].type) {
case ValidationErrors.REQUIRED:
errMessage = i18n('Field is required');
break;
case ValidationErrors.NOTVALID:
errMessage = i18n('Field is not valid');
break;
}
}
res.send(errMessage);
}
});
});