Include the Python traceback in the debug-page footer as a HTML comment

[Tom Forbes]

It would be very handy to include the traceback that triggered the Django debug page inside a HTML comment in the footer of the page. Quite often you might get a debug-page HTML output from tests or other places where it is inconvenient to try and find the actual cause of the exception - you have to page up through many kilobytes of HTML content to find the cause of the exception.

If we can include just a raw Python traceback in the footer of the debug page as a HTML comment then this will be immediately discoverable in such situations. print(html_response) and curl would both show it without needing any scrolling or grepping.

As a concrete example:

print(html)
.... lots of text

</div>
  <div id="explanation">
    <p>
      You’re seeing this error because you have <code>DEBUG = True</code> in your
      Django settings file. Change that to <code>False</code>, and Django will
      display a standard page generated by the handler for this status code.
    </p>
  </div>
<!--
Traceback (most recent call last):
  File "/path/to/example.py", line 4, in <module>
    greet('Chad')
  File "/path/to/example.py", line 2, in greet
    print('Hello, ' + someon)
NameError: name 'someon' is not defined
-->
</body>
</html>

[Mariusz Felisiak]

Thanks, I understand your intentions, but "raw" traceback is already included in the "Copy-and-past-view". IMO we shouldn't add traceback for the third time in the footer, it can be misleading and will make 500 responses even longer (I saw that you proposed adding it as a HTML comment).

... you might get a debug-page HTML output from tests or other places where it is inconvenient to try and find the actual cause of the exception - you have to page up through many kilobytes of HTML content to find the cause of the exception.

The technical 500 page is not really designed for tests. You can always use a custom 500.html for them.

[Tom Forbes]

I'd really like you to reconsider closing this. To put it in more general terms: the #1 use case for the debug page is to locate the error that caused the exception, and there are plenty of cases where you might have the raw HTML rather than viewing it in a browser. Right now the debug page is not helpful at all in this case.

It is indeed in the copy-paste view but that also involves grepping through *large* volumes of HTML to find it. I don't think it's a problem to include it in the footer, size doesn't matter for a debug page and the key metric is "the time it takes you to find the cause of the error". I cannot see how this does not help reduce that metric.

[Carlton Gibson]

Hi Tom.

I appreciate the pain in deciphering HTML in the middle of a failing test case. In any case where you're able to print(html_response) you should also be also to inspect ​`exc_info` which will also give you access to the exception (and the traceback) directly.

(If the TestClient should annotate responses with more info, this seems a much better way to go than, sorry-for-the-wording, littering the 500 template.)

Remember too, that you can set any Accepts header other than text/html to get a plain text error response.

In the curl case, piping into less and using searching for "Traceback " doesn't strike me as too burdensome...

I hope that makes sense.