Django Error Display Page

198 views
Skip to first unread message

Mateusz Harasymczuk

unread,
Jun 8, 2011, 6:50:14 AM6/8/11
to django-d...@googlegroups.com
Hi,
I have been thinking about this for quite a long time.

Can you make an error display page less verbose?
I mean not to exclude those useful information, but to initially fold (hide) them.

Fold those items:
- Python path at the top yellow background.
- (Hide or fold) django traceback entries

When I have a problem I have to scroll down (passing django calls) few pages until I am able to find which MY action caused an error.
I know looking at django callback may be useful, but in my case, hardly ever, and probably for newcommers also.

I am imagining this like that:

At the top of the error page, there are tabs.
Summary, Traceback, Request, Settings, and copy-paste view (feedback view).

Summary tab, contains this yellow background information with PYTHON_PATH initially folded, and traceback filtered out to include only information from project not calls from django itself.

Traceback, request and settings tabs as it is right now, but separated for easy of view.

copy-paste (feedback) - a standardize view for easy of copy-and-paste to the Internet message boards, groups and so on...

It would need a template refactor and some more js involved, should not be a hard thing to do.
I read that there is a plan to redesign an error page, but since then, those modifications should do the job.

What do you think?

--
Matt Harasymczuk

Graham King

unread,
Jun 8, 2011, 12:10:44 PM6/8/11
to django-d...@googlegroups.com
This ticket might be a part of what you're looking for:
https://code.djangoproject.com/ticket/11834
It proposes to dim the django parts of the stacktrace, so the code
which most likely caused the error stands out better, which is
certainly something I'd love to see.

There's some similar ideas discussed here:
https://groups.google.com/group/django-developers/browse_frm/thread/bd43e2e040a17784/?hl=de&pli=1

> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/b0pKaV9JR2gzXzRK.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-develop...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

Mateusz Harasymczuk

unread,
Jun 8, 2011, 12:44:02 PM6/8/11
to django-d...@googlegroups.com
Colored output of the trackeback does not solve my problem of scrolling few screens in order to find whats happening, or use cmd-F key to quick jump.
I think this is not a good way to do this.

What's I am thinking is a tabs at the top which manipulates with visibility of certain divs of error page.
A quick temporary fix, before complete redesign of error page.

bur...@gmail.com

unread,
Jun 8, 2011, 11:36:11 PM6/8/11
to django-d...@googlegroups.com
Hi Mateusz,

I think, adding a link at top, getting you to the end of traceback
would be suitable and would work 96% of times.

e.g, top line with exception type and URL could be a link moving you
to the end of traceback, where the exception happened.

What do you think?

Smart (colored) traceback could change that to moving to the last
piece of code which is not django code, but to be really usable, one
would have to customize it (i.e, to add info what 3rd-party packages
you use), which I feel is wrong.
Tabs would also have this problem, and also that without django lines
traceback would be much less readable.

> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/django-developers/-/d0F2R2NvWkJNQ3NK.


> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-develop...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

--
Best regards, Yuri V. Baburov, Skype: yuri.baburov, MSN: bu...@live.com

Tom Evans

unread,
Jun 9, 2011, 4:51:56 AM6/9/11
to django-d...@googlegroups.com

I disagree entirely. The stack trace is the first thing I look at, and
whilst we need to make it easy for people to learn django, we
shouldn't be hiding essential information from people - even if it is
just hidden in a separate 'tab'.

I also strongly disagree about manipulating the traceback at all. Why
would I not want to see where it went wrong inside Django? I also
don't buy the 'too much information' argument, I have never been in a
situation where a crash report has too much information - most of the
time it doesn't have enough.

Besides which, if the django error page is not what you desire, you
can always write your own middleware to produce your own error page.
If you really want to change how django's default error page looks
like, producing your own version first would be more compelling (and
less bikesheddy).

Cheers

Tom

Jonathan Slenders

unread,
Jun 9, 2011, 9:29:02 AM6/9/11
to Django developers


On 9 juin, 10:51, Tom Evans <tevans...@googlemail.com> wrote:
> I disagree entirely. The stack trace is the first thing I look at, and
> whilst we need to make it easy for people to learn django, we
> shouldn't be hiding essential information from people - even if it is
> just hidden in a separate 'tab'.


Me too. Why is it that I we have a huge Python Path, the Python
revision number and executeble locations on Top. Further, the
Exception value is displayed twice, and the request URL is also shown
in the address bar. The server time is also not that important that it
has to be shown above the stack trace.

I know it is possible to use a custom template for this, but I think
most people only want to see the Exception message, and the traceback
without scrolling down a whole page...

Idan Gazit

unread,
Jun 9, 2011, 10:16:11 AM6/9/11
to django-d...@googlegroups.com
The technical 500 page does display a lot of information, but debugging a failure is all about information.

#11834 is helpful (dims django frames) without getting in the way (hiding things). For now, this is a good example of a helpful change with minimal negative impact.

I'm sure the 500 page could be better, but I'd need to see a concrete proposal outlining the problems and how the improvements address these problems. Right now this feels like a case of fixing what ain't broken.

I

On Wednesday, June 8, 2011 at 6:10 PM, Graham King wrote:

> This ticket might be a part of what you're looking for:
> https://code.djangoproject.com/ticket/11834
> It proposes to dim the django parts of the stacktrace, so the code
> which most likely caused the error stands out better, which is
> certainly something I'd love to see.
>
> There's some similar ideas discussed here:
> https://groups.google.com/group/django-developers/browse_frm/thread/bd43e2e040a17784/?hl=de&pli=1
>

> > To post to this group, send email to django-d...@googlegroups.com (mailto:django-d...@googlegroups.com).


> > To unsubscribe from this group, send email to

> > django-develop...@googlegroups.com (mailto:django-develop...@googlegroups.com).


> > For more options, visit this group at
> > http://groups.google.com/group/django-developers?hl=en.
>

> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.

> To post to this group, send email to django-d...@googlegroups.com (mailto:django-d...@googlegroups.com).
> To unsubscribe from this group, send email to django-develop...@googlegroups.com (mailto:django-develop...@googlegroups.com).

Valentin Golev

unread,
Jun 9, 2011, 11:31:44 PM6/9/11
to Django developers
What I'd really like is a stacktrace in a plain text in the html
commentary ("<!-- ... -->") on the very top of the page.

This really would save me from curl's output reading nightmare without
losing all browser-understandable happiness

On Jun 9, 6:16 pm, Idan Gazit <i...@gazit.me> wrote:
> The technical 500 page does display a lot of information, but debugging a failure is all about information.
>
> #11834 is helpful (dims django frames) without getting in the way (hiding things). For now, this is a good example of a helpful change with minimal negative impact.
>
> I'm sure the 500 page could be better, but I'd need to see a concrete proposal outlining the problems and how the improvements address these problems. Right now this feels like a case of fixing what ain't broken.
>
> I
>
>
>
>
>
>
>
> On Wednesday, June 8, 2011 at 6:10 PM, Graham King wrote:
> > This ticket might be a part of what you're looking for:
> >https://code.djangoproject.com/ticket/11834
> > It proposes to dim the django parts of the stacktrace, so the code
> > which most likely caused the error stands out better, which is
> > certainly something I'd love to see.
>
> > There's some similar ideas discussed here:
> >https://groups.google.com/group/django-developers/browse_frm/thread/b...

Dougal Matthews

unread,
Jun 10, 2011, 3:34:44 AM6/10/11
to django-d...@googlegroups.com

On Friday, 10 June 2011 at 04:31, Valentin Golev wrote:

What I'd really like is a stacktrace in a plain text in the html
commentary ("<!-- ... -->") on the very top of the page.

+1
 
This would actually be very useful when debugging Ajax calls in browsers. I often find myself reading the HTML particularly in chrome where I think the only other option is to save the file and re-open it.

Dougal

Stephen Burrows

unread,
Jun 10, 2011, 9:05:38 AM6/10/11
to Django developers
That would be useful for Chrome and Safari, and probably pretty easy
to implement. (For Firefox, I like to use the Modify Headers add-on
[1] and spoof the AJAX request - then I can browse the error page in
its full glory. :-) )

--Stephen

[1] https://addons.mozilla.org/en-us/firefox/addon/modify-headers/

Wim Feijen

unread,
Jun 10, 2011, 10:42:21 AM6/10/11
to Django developers
For me, it would definitely be a good idea to change the error page a
bit, so at least the actual error message is not in grey but in black,
and bigger. People tend not to see it right now, because it looks
unimportant.

Wim

Daniel Watkins

unread,
Jun 10, 2011, 4:11:30 PM6/10/11
to django-d...@googlegroups.com
On Thu, Jun 09, 2011 at 08:31:44PM -0700, Valentin Golev wrote:
> What I'd really like is a stacktrace in a plain text in the html
> commentary ("<!-- ... -->") on the very top of the page.

I've opened https://code.djangoproject.com/ticket/16227 with patch
attached.


Regards,

Dan

David Cramer

unread,
Jun 11, 2011, 12:21:54 AM6/11/11
to Django developers
class EasyWin(object):
def process_exception(self, request, *args, **kwargs):
if not request.is_ajax(): return
impot traceback
return HttpResponse(traceback.format_exc())


On Jun 10, 1:11 pm, Daniel Watkins <dan...@daniel-watkins.co.uk>
wrote:

Mateusz Harasymczuk

unread,
Jun 11, 2011, 4:20:18 AM6/11/11
to django-d...@googlegroups.com
Why not to give ability to chose by the developer?

if settings.VERBOSE_DEBUG:
    as it is
else:
    tabbed view

or

DEBUG_VIEW = 'tabbed'
DEBUG_VIEW = 'default'
etc...

IMHO: DEBUG_VIEW is better and more extensible in future.
Reply all
Reply to author
Forward
0 new messages