Hi Thomas,

I don't have ready access to the Debian BTS, so I'm going to update here.

I don't 100% know what's going on here, but I think it is an issue with traceback2 which we started to exhibit after 55278e0 when we started to depend on it.

https://github.com/testing-cabal/traceback2/blob/master/traceback2/__init__.py#L449 assumes that if an exception has a __cause__, then the cause has a traceback. Clearly this assumption does not always hold.

__cause__ is normally set when an exception is re-raised using the new Python 3 raise from syntax. Python 3 correctly takes care of setting __traceback__ on __cause__.

However, it turns out that Django has special code for setting __cause__ on database exceptions:

As per PEP-3134, a __cause__ attribute is set with the original
(underlying) database exception, allowing access to any additional
information provided. (Note that this attribute is available under
both Python 2 and Python 3, although PEP-3134 normally only applies
to Python 3.)

(from exceptions.txt, some markup edits)

I would suggest that:

Django should be a little bit better behaved, and at least set __cause__.__traceback__ to None
traceback2 should be a bit more tolerant of poorly behaved exceptions, and wrap the access of __traceback__ in a getattr

Hope this helps,
jml

AttributeError: 'IntegrityError' object has no attribute '__traceback__' #162

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

AttributeError: 'IntegrityError' object has no attribute 'traceback' #162