Opened 6 years ago

Closed 2 years ago

Last modified 2 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

Description

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 (8)

comment:1 Changed 6 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

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 6 years ago by wojteks

  • Resolution invalid deleted
  • Status changed from closed to reopened

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 6 years ago by russellm

  • Resolution set to wontfix
  • Status changed from reopened to closed

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 6 years ago by adamnelson

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 follow-up: Changed 6 years ago by russellm

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 2 years ago by nbouliane

  • Easy pickings unset
  • Resolution wontfix deleted
  • Severity set to Normal
  • Status changed from closed to new
  • Type set to 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 2 years ago by aaugustin

  • Resolution set to wontfix
  • Status changed from new to closed

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 2 years ago by akaariai

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

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