Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

http 500 to be handled #16

Closed
zatarus opened this issue Jan 27, 2016 · 6 comments
Closed

http 500 to be handled #16

zatarus opened this issue Jan 27, 2016 · 6 comments

Comments

@zatarus
Copy link
Contributor

zatarus commented Jan 27, 2016

Any http 500 error causes log to have status code not assigned and response ms to 0. It would be nice to see the trace instead.

@aschn
Copy link
Owner

aschn commented Apr 3, 2016

@zatarus want to take a look at PR #18 and see if it works for you? thanks :)

@zatarus
Copy link
Contributor Author

zatarus commented Apr 9, 2016

Hey @aschn, thank you for taking time on this. I have found a behavior with drf, where if exception handler's response is empty, it will raise the exception itself (regardless of debug mode) and it will prevent mixin's handling to be called. Here is the location:

https://github.com/tomchristie/django-rest-framework/blob/78e4ea0d6e88a7b355ec3e790ef0e8f95859ca2d/rest_framework/views.py#L434

Default exception function by restframework also explains it as:

Any unhandled exceptions may return None, which will cause a 500 error to be raised.

so calling super handle_exception seems unreliable for anything that is not handled such as ParseError(), or raise of any exception other than APIException. In my case, I just wanted to cover all :)

Do you agree if calling super should be wrapped in try/except or I should implement my own exception class to wrap them all? If secondary, that implementation is fair already.

@triat
Copy link
Contributor

triat commented Mar 3, 2017

I think this one can be closed now with the new PR that you just merged @avelis

@avelis
Copy link
Collaborator

avelis commented Mar 3, 2017

@triat I will close it when I get a release out. Keeps me honest to get it out.

@triat
Copy link
Contributor

triat commented Mar 3, 2017

No worries :) I'm just trying to follow things correctly :) Thanks for your time

@avelis
Copy link
Collaborator

avelis commented Mar 8, 2017

Addressed in version 1.2.0 release.

@avelis avelis closed this as completed Mar 8, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants