Could we summarize in few words?
| DEBUG (development) | not DEBUG (production)
TEMPLATE_DEBUG | raise TemplateSyntaxError | ?
not TEMPLATE_DEBUG| ? | ?
On Sat, Jul 9, 2011 at 12:53 PM, Tai Lee <real.hu...@mrmachine.net> wrote:
>
>
> On Jul 9, 12:24 pm, Karen Tracey <kmtra...@gmail.com> wrote:
>> I'm strongly against that idea. Swallowing errors makes it incredibly
>> difficult to debug errors. I would prefer for the `TEMPLATE_DEBUG`
setting to
>> turn off much of the error-silencing currently done in template
processing.
>> Yes, that means different behavior during development compared to
>> production. But running with DEBUG (template or otherwise) on IS
different
>> from production, that's a given. And it this case it would allow for more
>> effective development since errors wouldn't be hidden away in nearly
>> impossible-to-find places. In my mind that's a tradeoff well worth
making.
>>
>> See ticket #13167 for one example of where "template errors" have not
been
>> silenced since before 1.0. If that case is to be be "fixed" now, I would
>> very much want that silencing to ONLY happen when TEMPLATE_DEBUG is
False.
>> In my opinion silencing these during development would be a huge step
>> backwards.
>
> I think we are in agreement here. Swallowing errors makes it
> incredible difficult to debug errors. I would like to see the
> circumstances when exceptions are swallowed be more clearly defined,
> and ensure that only exceptions that are expected to be swallowed, are
> swallowed. If we can do that, then there should be no need for the
> behaviour to change based on the `TEMPLATE_DEBUG` setting.
>
> The problem with the inconsistent behaviour associated with this
> setting is exceptions that are expected to be swallowed, that we want
> to be swallowed, are not being swallowed in some cases when
> `TEMPLATE_DEBUG = True`. This can make it impossible to access some
> URLs on a website where such a condition is present, even though there
> is no actual error and the exception is expected to be silenced. It
> also results in some exceptions being transformed into
> `TemplateSyntaxError` sometimes, and the true exception raised other
> times.
>
> See ticket #16147 for an example where `TemplateDoesNotExist` is
> raised when the template DOES exist, because a template tag inside the
> template being loaded raises `TemplateDoesNotExist` at compile time,
> only when `TEMPLATE_DEBUG = True`.
>
> This can make it impractical to develop locally with `TEMPLATE_DEBUG =
> True`, because it can prevent access to working pages, which means you
> miss out on all the enhanced debugging that `TEMPLATE_DEBUG = True`
> provides when you encounter an actual error that needs developer
> attention.
>
> With the intent being that template authors should not be able to
> trigger HTTP 500 errors on a production site, couldn't we achieve that
> by silencing exceptions raised when an invalid argument was passed to
> a template tag (e.g. `ValueError` or `TypeError` in the template tag
> code), but allowing exceptions raised in the code for the object that
> was passed in to the template tag as an argument?
>
> For example, if an object that calculates and returns a number when
> evaluated is passed to `{% widthratio %}`, but there is a bug in the
> code of that object and it raises some kind of exception when
> evaluated, that should not be silenced. It should bubble up so that
> the developer is alerted to a problem in the code for that object (not
> an error that the template author has made by passing an invalid
> argument). However, if there was no exception raised in evaluating the
> object, but it simply returned something other than a number, then
> that should behave the same as if an empty string or missing template
> variable was passed in and no exception should be raised.
>
> I think that a `TemplateSyntaxError` should be raised at compile time
> if an invalid template tag is used (unknown, too few or too many
> arguments). The `render()` function for a template tag should silence
> exceptions raised when arguments with the incorrect type or value are
> provided, but should not silence exceptions raised when evaluating the
> arguments themselves (or properties on the arguments).
>
> Cheers.
> Tai.
>
> --
> You received this message because you are subscribed to the Google Groups
"Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
>
>
--
Best regards, Yuri V. Baburov, Skype: yuri.baburov, MSN: bu...@live.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
