Opened 9 years ago

Closed 6 years ago

Last modified 3 years ago

#11909 closed Uncategorized (wontfix)

Django 'eating up' method errors in templates

Reported by: wojteks Owned by: nobody
Component: Template system Version: 1.1
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


When I'm working with an object in a template and I do the following:

  {{ some_model.some_method }}

and if inside that method an AttributeError is thrown for some reason - that error is hidden by Django completely. I get no error message - even though I have all the debugging turned on. And then I have to take the time to guess where the error was and surround the body of some_method with try/catch and debug it by hand.

Change History (9)

comment:1 Changed 9 years ago by Russell Keith-Magee

Resolution: invalid
Status: newclosed

This is by design. Django's template language eats errors and outputs an empty string. A style decision has been made that it is better to display nothing than to display a raw Python exception.

comment:2 Changed 9 years ago by wojteks

Resolution: invalid
Status: closedreopened

That's great. Don't display anything then. But log to the console at least if debug is enabled. For christs sake Django's design doesn't state that it's supposed to add man-hours to product development through hiding errors and exceptions from the programmer?

comment:3 Changed 9 years ago by Russell Keith-Magee

Resolution: wontfix
Status: reopenedclosed

Swearing will get you nowhere.

Neither will ignoring Django's process. If you disagree with a decision that has been made, then follow the well documented process and start a discussion on Django Developers.

Implying that the Django core developers (of which I am one) are simpering morons won't get you far either. You seem to be forgetting that I, the other core developers, and *many* other people have been using Django for a *lot* longer than you, and yet somehow we haven't had the entirety of our development life sucked into a black hole of hidden template errors.

I'm open to any reasonable suggestion for how to improve Django. My tolerance for irrational ranting is remarkably short.

comment:4 Changed 9 years ago by Adam Nelson

I would add in support of @wojteks that something missing from Django development is that everybody developing it has used it for years and therefore is blind to the needs of seasoned programmers coming to it from other languages/frameworks.

Anyway, it is the way it is. There is no way that I know of to get those errors.

I would suggest that the TEMPLATE_DEBUG documentation have a note saying that AttributeErrors are not available even when TEMPLATE_DEBUG is set to True.

comment:5 Changed 9 years ago by Russell Keith-Magee

Adam - As I said in my previous comment, I'm open to any suggestions on how we can improve Django, provided (1) that discussion is reasoned and rational, and (2) it happens in the right place. @wojteks comments were neither.

comment:6 in reply to:  5 Changed 6 years ago by nbouliane

Easy pickings: unset
Resolution: wontfix
Severity: Normal
Status: closednew
Type: Uncategorized
UI/UX: unset

I find it sad that this ticket was closed over such drama. It is a genuine issue that indeeds costs us development time. It is unexpected behavior, and it does cause problems.

comment:7 Changed 6 years ago by Aymeric Augustin

Resolution: wontfix
Status: newclosed

I find it sad that you didn't read comment 3 :)

If you genuinely want to move forwards on this issue, please write to the DevelopersMailingList.

Also, please don't reopen tickets closed as wontfix by core developers.

Thank you.

comment:8 Changed 6 years ago by Anssi Kääriäinen

Minor correction to this ticket - Django doesn't hide stack traces from failed method calls by design. This happens only for some exception types. This can be somewhat annoying but isn't intentional (otherwise all types of exceptions would be rendered to silent variable failures). There is a technical reason though - how do you detect that an object doesn't have an attribute? By AttributeError. And similarly TypeError is needed to check if a method is callable without arguments. See template/ _resolve_lookup for details.

So, I'd say that the reasons why certain types of errors are swallowed is template resolution semantics. Raising these errors without changing the semantics seems pretty much impossible. So wontfix is the right resolution (even if the original AttributeError case seems to be solved for method calls in master).

comment:9 Changed 3 years ago by Petr Dlouhý

There is hacky way with assigning handler object to the string_if_invalid variable, which work quite well in my oppinion:

The main problem is, that there is not enough information for complete error report. So I suggest adding an official invalid string handler, which would have at least the request, template path and the faulty string as parameters.

It could be taken even further, and set of default handlers could be implemented in Django with levels like silent, warning and exception, where the silent handler would be the default.

Note: See TracTickets for help on using tickets.
Back to Top