Re: Exceptions caught by the "include" template tag make it hard to rely on tests

[Jon Dufresne]

> Has anyone relied on the exception silencing behavior as a "feature" when
using {% include %}?

Not here.

+1 on deprecating the silencing behavior.

I have created a ticket [0] and PR [1] so others may get a sense of the
bigger picture change and how it could affect Django. Feedback welcome.

More generally, I find the template engine's behavior of replacing
exceptions with an empty string to cause more bugs than it prevents. In my
experience, loud errors will more likely be caught during development, unit
tests, and manual testing.

[0] https://code.djangoproject.com/ticket/27175
[1] https://github.com/django/django/pull/7208

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADhq2b7%3Daxpcduaas68ihWugLhiffTPmAx0bQoyTy%3Dsa8Sq7GA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Exceptions caught by the "include" template tag make it hard to rely on tests

[Sergei Maertens]

No, this is actually one of the reasons I keep recommending people to use 
inclusion tags as opposed to the {% include %} tag, and I see the same 
recommendation/reasoning in the IRC channel.

On Tuesday, July 12, 2016 at 12:36:11 AM UTC+2, Tim Graham wrote:
>
> Has anyone relied on the exception silencing behavior as a "feature" when 
> using {% include %}? It doesn't seem that's really possible given you can't 
> use that feature when template.debug=True. Thus, the current behavior 
> doesn't strike me as a reasonable default. Perhaps we can change it after a 
> deprecation. Does anyone really want an alternative to keep the silencing 
> behavior?
>
> From a user's perspective, I think it's more confusing to see a partial 
> and possibly broken page (but not necessarily knowing that it's broken) 
> than an error page.
>
> On Monday, July 11, 2016 at 6:17:58 PM UTC-4, Shai Berger wrote:
>>
>> On Monday 11 July 2016 22:45:31 Florian Apolloner wrote: 
>> > On Monday, July 11, 2016 at 7:56:34 PM UTC+2, Tim Graham wrote: 
>> > > As for me as a developer, I'd support removing the exception 
>> silencing 
>> > > that {% include %} does so that errors appear alongside any other 
>> > > exceptions (e.g. in Sentry) rather than in the django.template logger 
>> > > (that logging was added in Django 1.9). 
>> > 
>> > Dito, most tags should error out where it makes sense, but not sure if 
>> we 
>> > can easily change that :( 
>>
>> It must be opt-in; now that we have template engines and they're 
>> configured in 
>> dictionaries, we have plenty of room for that, though. 
>>
>> Another option to consider is make them error out only under the 
>> test-client. 
>>
>> My 2 cents, 
>> Shai. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/15102754-c381-45ea-9b57-61b31c6e791f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Exceptions caught by the "include" template tag make it hard to rely on tests

[Tim Graham]

Has anyone relied on the exception silencing behavior as a "feature" when 
using {% include %}? It doesn't seem that's really possible given you can't 
use that feature when template.debug=True. Thus, the current behavior 
doesn't strike me as a reasonable default. Perhaps we can change it after a 
deprecation. Does anyone really want an alternative to keep the silencing 
behavior?

>From a user's perspective, I think it's more confusing to see a partial and 
possibly broken page (but not necessarily knowing that it's broken) than an 
error page.

On Monday, July 11, 2016 at 6:17:58 PM UTC-4, Shai Berger wrote:
>
> On Monday 11 July 2016 22:45:31 Florian Apolloner wrote: 
> > On Monday, July 11, 2016 at 7:56:34 PM UTC+2, Tim Graham wrote: 
> > > As for me as a developer, I'd support removing the exception silencing 
> > > that {% include %} does so that errors appear alongside any other 
> > > exceptions (e.g. in Sentry) rather than in the django.template logger 
> > > (that logging was added in Django 1.9). 
> > 
> > Dito, most tags should error out where it makes sense, but not sure if 
> we 
> > can easily change that :( 
>
> It must be opt-in; now that we have template engines and they're 
> configured in 
> dictionaries, we have plenty of room for that, though. 
>
> Another option to consider is make them error out only under the 
> test-client. 
>
> My 2 cents, 
> Shai. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4c2355dc-9ddd-4bad-9677-78cb181f1a32%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Exceptions caught by the "include" template tag make it hard to rely on tests

[Shai Berger]

On Monday 11 July 2016 22:45:31 Florian Apolloner wrote:
> On Monday, July 11, 2016 at 7:56:34 PM UTC+2, Tim Graham wrote:
> > As for me as a developer, I'd support removing the exception silencing
> > that {% include %} does so that errors appear alongside any other
> > exceptions (e.g. in Sentry) rather than in the django.template logger
> > (that logging was added in Django 1.9).
> 
> Dito, most tags should error out where it makes sense, but not sure if we
> can easily change that :(

It must be opt-in; now that we have template engines and they're configured in 
dictionaries, we have plenty of room for that, though.

Another option to consider is make them error out only under the test-client.

My 2 cents,
Shai.

Re: Exceptions caught by the "include" template tag make it hard to rely on tests

[Florian Apolloner]

On Monday, July 11, 2016 at 7:56:34 PM UTC+2, Tim Graham wrote:
>
> As for me as a developer, I'd support removing the exception silencing 
> that {% include %} does so that errors appear alongside any other 
> exceptions (e.g. in Sentry) rather than in the django.template logger (that 
> logging was added in Django 1.9).
>

Dito, most tags should error out where it makes sense, but not sure if we 
can easily change that :( 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9aad091e-63ad-42dd-bc67-87bb3ef91e5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Exceptions caught by the "include" template tag make it hard to rely on tests

[Tim Graham]

Found in another thread [0]: "Some time in late 2003, Adrian and I decided 
that errors in templates  were best handled silently - the idea was that it 
would prevent untrained template editors from being able to 500-error a 
site with a typo."

And another [1]: "The broad reasoning is that a partial page rendering is 
preferable to a 500 error when rendering a template. This is driven by 
production requirements -- the end user shouldn't ever see a 500 error."

As for me as a developer, I'd support removing the exception silencing that 
{% include %} does so that errors appear alongside any other exceptions 
(e.g. in Sentry) rather than in the django.template logger (that logging 
was added in Django 1.9).

[0] 
https://groups.google.com/d/msg/django-developers/8yMzgEWsLl4/H7ITMVMkZcwJ
[1] 
https://groups.google.com/d/msg/django-developers/KpDS2tWLp7U/y7zli4P79nkJ

On Monday, July 11, 2016 at 4:06:11 AM UTC-4, Sylvain Fankhauser wrote:
>
> Hi,
>
> I'm bringing this back to the table since I can't believe I'm the only one 
> to find this behaviour weird and possibly dangerous. I'd really be 
> interested in getting your opinion on this!
>
> Thanks,
> Sylvain
>
> 2016-06-09 14:37 GMT+02:00 Sylvain Fankhauser  >:
>
>> Hi all,
>>
>> I got really frustrated today trying to understand why a bug could get 
>> past my test suite but fail in my dev environment. Finally Baptiste 
>> Mispelon pointed me to the include template tag documentation 
>> :
>>
>> If the included template causes an exception while it’s rendered 
>>> (including if it’s missing or has syntax errors), the behavior varies 
>>> depending on the template engine's debug option (if not set, this option 
>>> defaults to the value of DEBUG). When debug mode is turned on, an exception 
>>> like TemplateDoesNotExist or TemplateSyntaxError will be raised. When debug 
>>> mode is turned off, {% include %} logs a warning to the django.template 
>>> logger with the exception that happens while rendering the included 
>>> template and returns an empty string.
>>>
>>
>> That's a real problem when running tests, because since the exception is 
>> just silenced your tests will still pass although there was actually some 
>> error in your code. The current way to deal with this is, I guess, to set 
>> the template engine DEBUG option to True in the test environment but that 
>> doesn't seem right to me.
>>
>> I don't have a solution right now and I know this would be a big 
>> backwards incompatible change and the chances for this to change are 
>> abysmally low. But maybe we could just add an option for that (to make 
>> exceptions pop out of the include tag), set its default value to match the 
>> current behaviour, and change it with a clear deprecation plan?
>>
>> Cheers,
>> Sylvain
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d8452749-e30f-4a91-af32-6cb862cb431d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Exceptions caught by the "include" template tag make it hard to rely on tests

[Sylvain Fankhauser]

Hi,

I'm bringing this back to the table since I can't believe I'm the only one
to find this behaviour weird and possibly dangerous. I'd really be
interested in getting your opinion on this!

Thanks,
Sylvain

2016-06-09 14:37 GMT+02:00 Sylvain Fankhauser 
:

> Hi all,
>
> I got really frustrated today trying to understand why a bug could get
> past my test suite but fail in my dev environment. Finally Baptiste
> Mispelon pointed me to the include template tag documentation
> :
>
> If the included template causes an exception while it’s rendered
>> (including if it’s missing or has syntax errors), the behavior varies
>> depending on the template engine's debug option (if not set, this option
>> defaults to the value of DEBUG). When debug mode is turned on, an exception
>> like TemplateDoesNotExist or TemplateSyntaxError will be raised. When debug
>> mode is turned off, {% include %} logs a warning to the django.template
>> logger with the exception that happens while rendering the included
>> template and returns an empty string.
>>
>
> That's a real problem when running tests, because since the exception is
> just silenced your tests will still pass although there was actually some
> error in your code. The current way to deal with this is, I guess, to set
> the template engine DEBUG option to True in the test environment but that
> doesn't seem right to me.
>
> I don't have a solution right now and I know this would be a big backwards
> incompatible change and the chances for this to change are abysmally low.
> But maybe we could just add an option for that (to make exceptions pop out
> of the include tag), set its default value to match the current behaviour,
> and change it with a clear deprecation plan?
>
> Cheers,
> Sylvain
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAAXOc44qh%2B6iNkh5B6C_oYEo2dks-MQUi19SmZHJA6X_BJZh2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Exceptions caught by the "include" template tag make it hard to rely on tests

[Sylvain Fankhauser]

Hi all,

I got really frustrated today trying to understand why a bug could get past
my test suite but fail in my dev environment. Finally Baptiste Mispelon
pointed me to the include template tag documentation
:

If the included template causes an exception while it’s rendered (including
> if it’s missing or has syntax errors), the behavior varies depending on the
> template engine's debug option (if not set, this option defaults to the
> value of DEBUG). When debug mode is turned on, an exception like
> TemplateDoesNotExist or TemplateSyntaxError will be raised. When debug mode
> is turned off, {% include %} logs a warning to the django.template logger
> with the exception that happens while rendering the included template and
> returns an empty string.
>

That's a real problem when running tests, because since the exception is
just silenced your tests will still pass although there was actually some
error in your code. The current way to deal with this is, I guess, to set
the template engine DEBUG option to True in the test environment but that
doesn't seem right to me.

I don't have a solution right now and I know this would be a big backwards
incompatible change and the chances for this to change are abysmally low.
But maybe we could just add an option for that (to make exceptions pop out
of the include tag), set its default value to match the current behaviour,
and change it with a clear deprecation plan?

Cheers,
Sylvain

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAAXOc46M7jbPtF2rBZsOjod-Wm%2BatCtbpuTaFE%2BFgxhc4gSqCw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.