This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dingo_dasher
Recipients dingo_dasher
Date 2014-10-06.23:53:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1412639593.33.0.263693537062.issue22573@psf.upfronthosting.co.za>
In-reply-to
Content
I am using Flask, and I had the following code:

        modules = models.Module.query.join(models.ModuleAccess).\
                         filter(models.Model.owner_id == current_user.id).\
                         filter(models.ModuleAccess.user_id == current_user.id).\
                         filter(models.ModuleAccess.module_id == models.Module.id).\
                         filter(models.ModuleAccess.write_access == True)

This code had a bug -> "models.Model.owner_id" in the first line. This was a typo, and Python gave me an AttributeError, just as I would expect. However, this is the error I was given:

Traceback (most recent call last):
  File "/usr/local/lib/python3.4/dist-packages/flask/app.py", line 1836, in __call__
    return self.wsgi_app(environ, start_response)
  File "/usr/local/lib/python3.4/dist-packages/flask/app.py", line 1820, in wsgi_app
    response = self.make_response(self.handle_exception(e))
  File "/usr/local/lib/python3.4/dist-packages/flask/app.py", line 1403, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/local/lib/python3.4/dist-packages/flask/_compat.py", line 33, in reraise
    raise value
  File "/usr/local/lib/python3.4/dist-packages/flask/app.py", line 1817, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/local/lib/python3.4/dist-packages/flask/app.py", line 1477, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/local/lib/python3.4/dist-packages/flask/app.py", line 1381, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/local/lib/python3.4/dist-packages/flask/_compat.py", line 33, in reraise
    raise value
  File "/usr/local/lib/python3.4/dist-packages/flask/app.py", line 1475, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/local/lib/python3.4/dist-packages/flask/app.py", line 1461, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/usr/local/lib/python3.4/dist-packages/flask_login.py", line 758, in decorated_view
    return func(*args, **kwargs)
  File "/home/dingo/UIM/app/views.py", line 175, in modules
    filter(models.ModuleAccess.write_access == True)
AttributeError: 'module' object has no attribute 'Model'

It shows me the last line of that long statement, "models.ModuleAccess.write_access == True" as the beginning of the trace. The trace doesn't show the models.Module.whatever line that actually caused the error.

It seems to be like Python here takes the last line of the exception-causing statement and shows that along with the "actual" error message (which was on the money): AttributeError: 'module' object has no attribute 'Model'

This seems to me slightly misleading. I submit that a better behaviour would be to show the line that caused the exception (I assume/hope that is possible since python knew it was accessing the Model attribute of the module object that caused the error).

I classified this as a behaviour bug rather than an enhancement, because I believe this would not be intended behaviour. I don't know if that's the case.

I apologise if this doesn't fit in "Intepreter core", but exceptions are builtins... I didn't know where else to put it.
History
Date User Action Args
2014-10-06 23:53:13dingo_dashersetrecipients: + dingo_dasher
2014-10-06 23:53:13dingo_dashersetmessageid: <1412639593.33.0.263693537062.issue22573@psf.upfronthosting.co.za>
2014-10-06 23:53:13dingo_dasherlinkissue22573 messages
2014-10-06 23:53:12dingo_dashercreate