Skip to content

Explicitly raise exc in 'raise_uncaught_exception' #6435

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

Merged
merged 1 commit into from
Mar 7, 2019

Conversation

rpkilby
Copy link
Member

@rpkilby rpkilby commented Feb 2, 2019

ref #6404

My greatest contribution yet 😄

Although, knowing my luck, this will break something.

Copy link
Collaborator

@carltongibson carltongibson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Python Tutorial has it as “...a simpler form of the raise statement...” but the change is equivalent in the normal case.

@tomchristie
Copy link
Member

A sanity check that we might? want to try. Raise an exception in a view and double check if the traceback ends up the same before and after this change.

(Or we could just hit go, which I’m probably okay with)

@rpkilby
Copy link
Member Author

rpkilby commented Mar 1, 2019

So I just checked, and the change is a very slight improvement. A bare raise seems to exclude the line from the traceback, while explicit raise does add itself to the traceback.

Here was a quick test that I added to test_views.py:

class TestTestTestTest(TestCase):
    def setUp(self):
        self.view = ErrorView.as_view()

    def test_get_exception_handler(self):
        request = factory.get('/', content_type='application/json')
        response = self.view(request)
        print(response.status_code)
        print(response.data)

Traceback w/ bare raise:

tests/test_views.py:153: in test_get_exception_handler
    response = self.view(request)
.tox/venvs/py37-django21/lib/python3.7/site-packages/django/views/decorators/csrf.py:54: in wrapped_view
    return view_func(*args, **kwargs)
.tox/venvs/py37-django21/lib/python3.7/site-packages/django/views/generic/base.py:68: in view
    return self.dispatch(request, *args, **kwargs)
rest_framework/views.py:495: in dispatch
    response = self.handle_exception(exc)
rest_framework/views.py:455: in handle_exception
    self.raise_uncaught_exception(exc)
rest_framework/views.py:492: in dispatch
    response = handler(request, *args, **kwargs)
tests/test_views.py:45: in get
    raise Exception
E   Exception

Exception with explicit raise:

tests/test_views.py:153: in test_get_exception_handler
    response = self.view(request)
.tox/venvs/py37-django21/lib/python3.7/site-packages/django/views/decorators/csrf.py:54: in wrapped_view
    return view_func(*args, **kwargs)
.tox/venvs/py37-django21/lib/python3.7/site-packages/django/views/generic/base.py:68: in view
    return self.dispatch(request, *args, **kwargs)
rest_framework/views.py:495: in dispatch
    response = self.handle_exception(exc)
rest_framework/views.py:455: in handle_exception
    self.raise_uncaught_exception(exc)
rest_framework/views.py:466: in raise_uncaught_exception
    raise exc
rest_framework/views.py:492: in dispatch
    response = handler(request, *args, **kwargs)
tests/test_views.py:45: in get
    raise Exception
E   Exception

I'd say the more complete traceback makes more sense, in addition to the points I made in #6404 (comment).

I don't think there's any specific test to be added though? We'd just be testing Python's exception handling?

@tomchristie tomchristie merged commit fd32dd7 into encode:master Mar 7, 2019
@tomchristie
Copy link
Member

Brill. Yes.

@rpkilby rpkilby deleted the fix-uncaught-exception-handling branch March 7, 2019 22:21
rpkilby added a commit that referenced this pull request May 10, 2019
Python 2 loses the exception context with an explicit `raise exc`,
making debugging significantly more difficult.
pchiquet pushed a commit to pchiquet/django-rest-framework that referenced this pull request Nov 17, 2020
sigvef pushed a commit to sigvef/django-rest-framework that referenced this pull request Dec 3, 2022
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

Successfully merging this pull request may close these issues.

3 participants