Tracking back exceptions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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






--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/981d4392-500f-4463-b30c-786cbad21d99%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Tracking back exceptions

Tim Graham-2
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.

On Friday, January 5, 2018 at 6:00:26 PM UTC-5, Stephan Doliov wrote:
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






--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1491e92f-9acd-4e10-9887-1a0e86f8b337%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.