You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when a generated sync function throws an authorization or validation error, it does so as a plain object as suggested by the official CouchDB developer docs. For example:
throw{forbidden: 'Unknown document type'};
While this is technically valid JavaScript, it produces a less desirable result when using the test-fixture-maker module to validate document definitions. Specifically, mocha generates a message that can be a little confusing/misleading if an unexpected validation error occurs in a test case. For example:
Error: the object {
"forbidden": "Invalid hashtableDoc document: hashtable \"staticSizeValidationProp\" must not be smaller than 3 elements"
} was thrown, throw an Error :)
Despite being a cheerful reminder that it is preferable to throw an Error object, the message can be confusing to the user since they may not be aware of that implementation detail. CouchDB interprets all thrown Error objects as 500 Internal Server Error, so validation functions themselves should not throw an Error object. Instead, the test-environment-maker should wrap validation functions in a try-catch block that wraps a plain thrown object in an Error object with its forbidden property set accordingly in such instances.
…r permissions
Throwing an Error object results in more meaningful error messages when there are unexpected authorization or validation failures in test cases.
Feature Request
Description
Currently, when a generated sync function throws an authorization or validation error, it does so as a plain object as suggested by the official CouchDB developer docs. For example:
While this is technically valid JavaScript, it produces a less desirable result when using the test-fixture-maker module to validate document definitions. Specifically, mocha generates a message that can be a little confusing/misleading if an unexpected validation error occurs in a test case. For example:
Despite being a cheerful reminder that it is preferable to throw an Error object, the message can be confusing to the user since they may not be aware of that implementation detail. CouchDB interprets all thrown Error objects as 500 Internal Server Error, so validation functions themselves should not throw an Error object. Instead, the test-environment-maker should wrap validation functions in a try-catch block that wraps a plain thrown object in an Error object with its
forbidden
property set accordingly in such instances.Examples
In
test-environment-template.js
:The text was updated successfully, but these errors were encountered: