Tracking back exceptions

[Stephan Doliov]

I posted a similar query in django-users and haven't heard back yet, perhaps because I didn't formulate my inquiry clearly or because my inquiry gets deeper into django internals than a django-user post should.

I have a situation, python 3.5, Django 2.0, Django Rest Framework 3.7.7 and I want to be able to see what faulty post data (JSON format) triggered a parse error. Using pdb, I found that as rest_framework handles the request, it hands off the body parsing to the json decoder module and that it should trigger a json.decoder.JSONDecodeError (and it does) but that JSONDecodeError raises a ValueError in its initialization without passing along the input json data. DRF intercepts the Value error as a ParserError and shows the generic portion of that error, as in 

JSON parse error - Unterminated string starting at: line 1 column 40 (char 39)

The JSONDecodeError object has an attribute

doc

that contains the input data. I would love to be able to extract this input data once that error is raised, to understand if there is a pattern out there to clients that malform JSON before attempting to POST it.

From my point of view, it looks like

JSONDecodeError raises ValueError raises ParseError. I'd love to see the attributes of the underlying exception, in this case, JSONDecodeError. But I cannot because, it seems, as far as django is concerned, only a ParseError was raised as a light wrapper to ValueError.

There would be many ways to get at this if it were a burning issue for me; I could write a custom json.decoder.JSONDecodeError class (of which there are several conceivable variations to bubble the JSONDecodeError.doc attribute back up to the DRF ParseError. But it seems to me to be a more fundamental to Django's design question:

Should django only be aware of the most recent error that is raised? If so, why? Or is there already a way around this such that I could readily see the JSONDecodeError.doc attribute once DRF raises its ParseError?

Thoughts?

-steve

[Tim Graham]

Hi Steve, Please avoid the temptation to use this mailing list as a second level support channel. If you have a better understanding of the problem and want to propose a change to Django, then it would be appropriate to post here.