Neste ponto, parece lógico acreditar em como o mangusto lida com os erros.
Você não gostaria que seus modelos tratassem de mensagens de erro. A camada de apresentação (controladores?) deve depender do
type para decidir qual é a melhor mensagem amigável a ser exibida (considerada i18n). Há também o caso em que a validação pode acontecer usando um middleware. Nesse caso, a mensagem de erro que aparecerá no seu controlador é o que você passar para o
next() ligar de volta. Portanto, para o caso de middleware, embora não documentado, para manter uma API de validação consistente em seus modelos, você deve usar diretamente os construtores Error do 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();
});
Dessa forma, você tem a garantia de um tratamento de erro de validação consistente, mesmo se o erro de validação se originar de um middleware.
Para corresponder corretamente as mensagens de erro aos tipos, eu criaria um enum que atuaria como um mapa estático para todos os tipos possíveis:
// 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);
}
});
});
