On Tue, 2007-05-01 at 05:42 -0700, sandro.dentella wrote: > hi all, > > I noticed that recently has been added InterityError as a common > exception > for all db (django.db.IntegrityError), so I wanted to make my view > aware > of that, but I'm uncertain on how to accomplish this. > > I added a snippet like this one, in a sort of generic view: > > if form.is_valid(): > # No errors -- this means we can save the data! except for db > problems > try: > new_object = form.save() > except IntegrityError: > new_object = None > form.errors['db'] = "Integrity Error from the db" > > if new_object: > if request.user.is_authenticated(): > ... > > if new_object is None it falls back to the branch of form error > handling... this was what I wanted... really it raises: > ProgrammingError, current transaction is aborted, commands ignored > until > end of transaction block. > > What's wrong and which should be a correct way to handle > IntegrityError?
If your code is raising ProgrammingError, then you have different problems to when the code is raising IntegrityError. The strong reason in favour of making IntegrityError available right now is because it is one thing we do not have complete control over: some other process may have changed the database in a way that is inconsistent with the change we want to make. For example, there might be a foreign key reference missing or a uniqueness violation or something like that. If your code is raising ProgrammingError, it means there is a problem in your code (bad SQL, for example). This is something that is completely within your control to fix, rather than not being detectable until it gets to the database server. ProgrammingErrors are completely fixable by the programmer, IntegrityErrors are not 100% avoidable. Now, of course, this all assumes that whichever backend you are using is compliant with the Python DB-API 2.0. Maybe it really is raising ProgrammingError when it should be raising IntegrityError, but I doubt it. As far as I know, all the database backends we support have sensible exception mappings. In the long-term it would be nice to maybe expose all the exceptions in a backend-neutral fashion, as we've done with IntegrityError. However, I would like to do that without having to list them all one by one, because that is very repetitive and adds bloat that the code reader has to skip over without adding much value. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
