There are multiple places in dynogels where a new Error object is thrown or passed to a callback in error position. We should use a dynogels-specific error instead of the built-in Error type so that dynogels errors can be distinguished from other errors in error-handling code.
I am particularly singling this line out. It makes it very difficult to automatically and reliably determine that this error is the result of a schema check. In our application, we detect Joi errors and automatically react by responding with an HTTP error code of 422 (unprocessable entity) but we are completely unable to do that with these errors since the Joi validation error is masked behind an untyped error.
There are multiple places in dynogels where a
new Errorobject is thrown or passed to a callback in error position. We should use a dynogels-specific error instead of the built-inErrortype so that dynogels errors can be distinguished from other errors in error-handling code.I am particularly singling this line out. It makes it very difficult to automatically and reliably determine that this error is the result of a schema check. In our application, we detect Joi errors and automatically react by responding with an HTTP error code of 422 (unprocessable entity) but we are completely unable to do that with these errors since the Joi validation error is masked behind an untyped error.