#17664: {% if %} template tag silences exceptions inconsistently
-------------------------------------+-------------------------------------
     Reporter:  Tai Lee              |                    Owner:  Robert
                                     |  Roskam
         Type:  Bug                  |                   Status:  assigned
    Component:  Template system      |                  Version:  master
     Severity:  Normal               |               Resolution:
     Keywords:  smart if tag         |             Triage Stage:  Accepted
  queryset exception silenced        |
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by Robert Roskam):

 So I've figured out what's going on here. We have 2 distant parts
 interacting here:

 (1) the templatetag if parser
 (‚Äčhttps://github.com/django/django/blob/master/django/template/smartif.py#L174)
 (2) the lookup_resolver
 (https://github.com/django/django/blob/master/django/template/base.py#L819)

 Template literals with no booleans operations are passed down through the
 if parser in (1) and no evaluation is down on them. All the capturing of
 values and forcing them to False is done in the infix and prefix functions
 of (1). Since both of these 2 previous things are true, any exception that
 is raised will be caught if it uses any boolean logic, so given that:


 {{{
 def _raise_exception():
     raise Exception
 a = _raise_exception
 }}}

 All of these will raises exceptions:

 {{{
 {% if a %}

 {% if a|length %}

 {% if a||add:"2" %}

 }}}

 However, all of these will coerce `a` to False:

 {{{

 {% if a == 1 %}

 {% if a and a%}

 {% if not not a %}

 }}}


 As best as I can tell, these are being totally consistent with their
 design intent. That is to say, they're operating exactly like the docs say
 they should. If we don't like the fact that {{{a}}} raises an error and
 {{{not a}}} doesn't, then I think we should make a deliberate design
 decision to do one or the other.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/17664#comment:21>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.248e30aab8459e1e2f12295b10d8ac39%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to