Django 'eating up' method errors in templates

[wojteks]

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.

[Russell Keith-Magee]

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.

[wojteks]

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?

[Russell Keith-Magee]

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.

[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.

[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.

[nbouliane]

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.

[Aymeric Augustin]

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.

[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/base.py _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).

[Petr Dlouhý]

There is hacky way with assigning handler object to the string_if_invalid variable, which work quite well in my oppinion: ​http://stackoverflow.com/questions/4300442/show-undefined-variable-errors-in-django-templates

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.

[Thomas Güttler]

You can use the ​pytest-django setting FAIL_INVALID_TEMPLATE_VARS

The invaild vars get checked if pytest executes the code.

[pytest]
DJANGO_SETTINGS_MODULE = mysite.settings
FAIL_INVALID_TEMPLATE_VARS = True