Make TECHNICAL_500 more resilient (against large variables and non-utf-8)

[Walter Doekes]

Hi,

I recently had errors that didn't provide a nice TECHNICAL_500_TEMPLATE mail.

The cause turned out to be two things:
(1) large variables caused a mail so large that the MXs refused to deliver them
(2) non-utf8 representations of objects caused errors while handling the error

The attached fix fixed it.

This was done against Django 1.4. Apologies in advance if this is fixed somewhere already. I couldn't find a relevant bug report.

Triggering (1) should be a matter of generating an error up the stack with a huge variable. Triggering (2) can be done like this:

urlpatterns = (
    # Error test
    (r'500$', (lambda r: Crap())),  # ExplodeInYourFaceError
)

class Crap(Exception):
    def __init__(self):
        raise self
    def __repr__(self):
        return 'X\xe9X'

Regards,
Walter Doekes
OSSO B.V.

[wim@…]

Good idea to trim large variables.

Shouldn't objects always be presented in utf-8 unicode by default?

[Walter Doekes]

Shouldn't objects always be presented in utf-8 unicode by default?

Should and should. In this particular case it was (a) a third party lib (b) throwing an exception with binary data in the representation.

We can argue all day about whether that's right, but error reporting shouldn't choke on it.

[Tim Graham]

Duplicate of #20368