[API] Clean up exception raise/rescue usage, use 4xx and 5xx appropriately
- Most exceptions in API server result in 422, even if they arise from server bugs that the client doesn't have any hope of fixing.
- There is a specific list of exceptions that are rendered as 404.
- The render_error action asks the exception object for an http_status (
if respond_to?(:http_status)). PermissionDeniedError uses this.
- Model validation errors, and similar exceptions we generate in normal server operation, should render 422.
- Exceptions other than the expected ones should render 500.
render_error, default to 500.
- Make a subclass of
RequestError) with an http_status method that returns 422.
RequestErrorwith more specific error classes, returning different http_status if appropriate. For example,
- Use these new exceptions in some of the more obvious places. Over time we'll catch more 500s that should be 400s, and fix them.
- Report the name of the exception class in a separate hash key ("error_class"?) if the HTTP status code is 4xx. This can make it possible for clients to react appropriately to specific errors without having to parse the human-readable error message.
- In production mode, dump stack traces for 5xx but not 4xx. In dev mode, dump always. This should be accomplished by always dumping but using the appropriate log level (4xx debug vs. 5xx error) so the administrator still has the option of turning on 4xx stack traces.