What were the reasons or design decisions behind wrapping APIExceptions in an ErrorDetail object?

[deepaks829]

I am trying to understand the way DRF works internally to enable myself to extend the functionality to fit my specific needs. I highly appreciate the time you have taken to help me understand the design philosophy/choices behind DRF.

A very common scenario I keep coming across in many questions is users wanting to add more details to the error responses produced by DRF app. As described in the documentation, we can alter the style of the response, by adding a custom exception handler. However, speaking from a development standpoint, IMHO, it is much easier to add additional contextual information while raising the error and then simply serialize it into a desired representation rather than add the information after it is raised.

However, it seems like adding additional contextual information while raising the error is not a simple task if you subclass APIException, as it coerces the details into an ErrorDetail object. Why was this designed this way? If it was just using some dictionary like structure, it would have been much easier to subclass the APIException classes no?

We can get around all APIExceptions by defining our own exception classes derived from Exception and handling it in custom_exception_handler, except for ValidationErrors as this is raised in the Serializer, Field and Validator classes. One way I have found to get around this is to override the is_valid method and catch the serializers.ValidationError and raise my own CustomValidationError derived from Exception and include any additional fields as part of the initialization process and then handle it in the custom_exception_handler.

Thanks

[umut-firat]

I'm also trying to customize DRF's error schema to improve DX for my colleagues working in frontend so they can benefit that using it with TypeScript. Right now, I'm trying to achieve something simple like this below:

Note: details is going to be only shown on ValidationError

// TypeScript
interface ErrorSchema {
    code: string;
    message: string;
    details?: Record<string, string[]>;
}

# Python
{
    "code": "validation_error",
    "message": "Validation error occured.",
    "details": {
        "email": ["Email is not valid."],
    }
}

Even though I override exception_handler and create my own exceptions derived from APIException, I find myself struggling with issues like non_fields_errors used by UniqueTogetherValidator, which breaks my schema. I tried reading the source code, but I got lost in ErrorDetail, ReturnDict, ReturnList and _get_error_details.

I believe the lack of examples on this matter deserves serious attention.