Re: [Django] #11909: Django 'eating up' method errors in templates
Django
---------------------------------+--------------------------------------
Reporter: wojteks | Owner: nobody
Type: Uncategorized | Status: new
Component: Template system | Version: 1.1
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------
Changes (by nbouliane):
* status: closed => new
* severity: => Normal
* resolution: wontfix =>
* easy: => 0
* ui_ux: => 0
* type: => Uncategorized
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/11909#comment:6>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
---------------------------------+--------------------------------------
Reporter: wojteks | Owner: nobody
Component: Template system | Version: 1.1
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------
* status: new => closed
* resolution: => wontfix
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/11909#comment:7>
Django
---------------------------------+--------------------------------------
Reporter: wojteks | Owner: nobody
Type: Uncategorized | Status: closed
Component: Template system | Version: 1.1
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------
Comment (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).
--
Ticket URL: <https://code.djangoproject.com/ticket/11909#comment:8>
Django
---------------------------------+--------------------------------------
Reporter: wojteks | Owner: nobody
Type: Uncategorized | Status: closed
Component: Template system | Version: 1.1
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------
Comment (by PetrDlouhy):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/11909#comment:9>
Django
---------------------------------+--------------------------------------
Reporter: wojteks | Owner: nobody
Type: Uncategorized | Status: closed
Component: Template system | Version: 1.1
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------
Comment (by Thomas Güttler):
You can use the [https://pytest-
django.readthedocs.io/en/latest/configuring_django.html#pytest-ini-
settings 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
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/11909#comment:10>