On 28 sept. 2013, at 11:56, Shai Berger <[email protected]> wrote: > Just a note -- option 2 has the potential (like PostgreSQL's error handling) > to hide the problems and make them very hard to debug. Consider a site using > ATOMIC_REQUESTS (equivalently, TransactionMiddleware) on a > statement-atomicity > database, whose code catches exceptions and continues working. While Option 2 > will detect the problems, the error report will only point at the query after > the problem, not the place that needs to be fixed. This is a very frustrating > experience: "You have an error somewhere before this point, go find it".
Indeed this is a valid concern. > If Option 2 is to be viable, it needs to be modified to store the original > problem and its traceback, and add them to the errors somehow. On Python 3, > exception chaining can be used; on Python 2, some other method needs to be > found. I believe it already works on Python 3, where the exception chain is automatically displayed when an exception occurs in an `except` clause. It looks possible to implement explicit transaction chaining by storing the exception whenever setting needs_rollback = False and adding it to the TransactionManagementError -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
