#11716: Various methods in django.db.models.fields don't wrap ValueErrors and
allow
them to escape
---------------------------------------------------+------------------------
Reporter: Leo | Owner: Leo
Status: assigned | Milestone: 1.2
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------------+------------------------
Comment (by Leo):
I'm not sure if you're stating that as a policy or as an argument for why
this fix shouldn't be taken. I don't have sufficient knowledge to argue
against it as a Django policy (although if that's the case, I will try and
figure out the best way to do so). I can, however, make a strong argument
for making this change on its own merits.
I agree with the principle of keeping the API consistent for a given
release but this is a case where the implementation of the API was broken.
If the point that you're making is that any code that relied on this
broken behavior will be broken once this bug is fixed, well, yes. Any
bugfix changes behavior and IMO a bugfix that causes an explicit loud
exception to get thrown is much better than one that may have not
immediately obvious side effects. As a random example of a bug that I've
worked on, take #5605 - someone relying on the 'incorrect' lowercasing
behavior and using a case sensitive DB backend may now have a very subtle
bug in their code when they upgrade to 1.2. One could easily find such
cases for pretty much any bug.
The consequences of not fixing this bug are fairly significant as
described in the example above and require client code to look
significantly uglier as well as become tied to the actual implementation
of any specific field. I just double checked the docs and `primary_key` is
just a method on `Field` so it can be applied to ANY field. Which in turn
means that if you abandon the API of requiring the `Field` to encapsulate
its internal working in a `ValidationError`, the catch statement in the
comments code has to catch pretty much any exception that could possibly
come out of the field. That should clearly not be the responsibility of
that client code.
--
Ticket URL: <http://code.djangoproject.com/ticket/11716#comment:14>
Django <http://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 post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
