res.negotiate()
This method is deprecated.
You should use a custom response instead.
To handle errors from Waterline model methods, check the
name
property of the error (see the Waterline error reference for more details).
Given an error (err
), attempt to guess which error response should be called (badRequest
, forbidden
, notFound
, or serverError
) by inspecting the status
property. If err
is not a dictionary, or the status
property does not match a known HTTP status code, then default to serverError
.
Especially handy for handling potential validation errors from Model.create() or Model.update().
return res.negotiate(err);
Like the other built-in custom response modules, the behavior of this method is customizable.
res.negotiate()
examines the provided error (err
) and determines the appropriate error-handling behavior from one of the following methods:
res.badRequest()
(400)res.forbidden()
(403)res.notFound()
(404)res.serverError()
(500)The determination is made based on err
's "status" property. If a more specific diagnosis cannot be determined (e.g. err
doesn't have a "status" property, or it's a string), Sails will default to res.serverError()
.
// Add Fido's birthday to the database:
Pet.update({name: 'fido'})
.set({birthday: new Date('01/01/2010')})
.exec(function (err, fido) {
if (err) return res.negotiate(err);
return res.ok(fido);
});
- This method is terminal, meaning it is generally the last line of code your app should run for a given request (hence the advisory usage of
return
throughout these docs).res.negotiate()
(like other userland response methods) can be overridden - just define a response module (/responses/negotiate.js
) and export a function definition.- This method is used as the default handler for uncaught errors in Sails. That means it is called automatically if an error is thrown in any request handling code, but only within the initial step of the event loop. You should always specifically handle errors that might arise in callbacks/promises from asynchronous code.