On Fri, 2009-02-20 at 22:22 +0100, Ludvig Ericson wrote: > On Feb 20, 2009, at 20:38, Ben Gerdemann wrote: > > > > > I just spent a good part of my afternoon tracking down a bug in my > > code, that eventually turned out to be a Unicode encoding problem. The > > reason it took me so long to track down the problem is this code here > > in 'template/__init__.py': > > > > 794 class VariableNode(Node): > > ... > > 801 def render(self, context): > > 802 try: > > 803 output = > > force_unicode(self.filter_expression.resolve > > (context)) > > 804 except UnicodeDecodeError: > > 805 # Unicode conversion can fail sometimes for reasons > > out of our > > 806 # control (e.g. exception rendering). In that case, > > we fail quietly. > > 807 return '' > > > > Is there a good reason that the widget rendering is silently capturing > > all Unicode errors? Now that I know that it's doing this, it won't > > take me so long to figure out the problem if it happens again, but it > > certainly wasn't expected behavior. At the very least, maybe we could > > return 'UnicodeDecodeError' instead of a blank string? > > I think this is a symptom of a much greater issue: the templating > system *silences* errors a lot.
Well, you'll need to come up with some concrete cases, since the general claim isn't really true (make that a different thread, though, since it's not the same topic as this one). We silence a particular set of errors: mostly those related to accessing non-existent variables. Those errors aren't a sign of a problem, necessarily, since it permits a wide range of template re-use as you don't need the full set of variables the template uses in order to use that template. There's a slight side-effect that other emitters of KeyError and AttributeError get bitten, that's true, but almost impossible to avoid. That's why TEMPLATE_STRING_IF_INVALID exists, since those problems can easily be detected at development time if they are happening inadvertently. The Unicode case is probably a situation where logging (or the addition of a logging hook) might be useful (since it's non-developer content and thus not necessarily detectable at development time). What other errors do you think are being unnecessarily silenced? Specifics are important here, as the silencing we are doing is generally deliberate and with fairly well thought-out reasons. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
