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
I like this package, because I know what a hassle the exception_handler can be.
I was wondering if you would consider moving to a more standardized format, like for example problem+json? This can of course be done as a setting.
Honestly, the main reason for making the handler easy to customize is allowing everyone to change the format to suit their requirements. Out of the box, I tried to have the default format support multiple errors (for validation errors) and make it easy to document with OpenAPI (always have the same format: errors is a list even if there is one error).
I gave the article a quick read and I don't think we should move to it as the default: it does not promote multiple errors by default, error codes will require a custom member and seems to promote more customization to the format depending on the error as opposed to keeping the format the same always. Still, I like your idea about making it a setting. So, what do you think about contributing this a custom ExceptionFormatter? it will serve as a good example of how to customize the error response and others can use it easily by updating the EXCEPTION_FORMATTER_CLASS setting. Also, it would be great if you can work on documenting it with drf-spectacular.
Here's a sample implementation that I saw a while ago for the same RFC that explains what I'm suggesting.
I like this package, because I know what a hassle the exception_handler can be.
I was wondering if you would consider moving to a more standardized format, like for example problem+json? This can of course be done as a setting.
Explanation problem+json: https://lakitna.medium.com/understanding-problem-json-adf68e5cf1f8. Specs: https://datatracker.ietf.org/doc/html/rfc7807
The text was updated successfully, but these errors were encountered: