On Jun 22, 2011, at 3:41 AM, Anton wrote: > On 22 июн, 01:31, Michael Bayer <mike...@zzzcomputing.com> wrote: >> On Jun 21, 2011, at 7:04 PM, Anton wrote: >> >>> On 22 июн, 00:47, Michael Bayer <mike...@zzzcomputing.com> wrote: >>>> I added StatementError after having too often a custom type or other kind >>>> of error happen deep inside the preparation for execution with no >>>> indication what statement or parameter caused the issue. It's an >>>> enhancement, and the original exception is associated with the new one as >>>> "orig". In Python 3 this works even more nicely as you can see we're >>>> doing "raise x from e", and you get both stacktraces. What about the >>>> StatementError is not working for you ? I'd advise against doing things >>>> like business-level validations in types. >> >>> In my case it's more like sanity check than business-logic. And the >>> reason to do this checks in type is that I want to delay it as much as >>> possible. It would be acceptable to have another exception instead of >>> custom, but the problem is that it is not easy to understand, what's >>> went wrong looking at the stack trace. It doesn't show at the last >>> line its original exception, only "StatementError: 'query >>> text' [params list]". >> >> well Python 3 fixes this problem entirely by allowing exception chains. >> What text would you prefer in StatementError ? > > Ideally it would work like it's used to in 0.5 and 0.6. Maybe, we may > do it like this: > > + if isinstance(e, exc.SQLAlchemyError): > + # don't suppress or reraise already handled exceptions > + return
Well, actually I'd like every exception that happens in an execution to include information about the statement, regardless of if a SQLAlchemy construct raised it or not. The very common use case is when a script is emitting hundreds of statements through a flush, then way deep inside, there's one bound value that blows up. A stack trace like that leads up to a mapper and the unit of work but otherwise gives no context at all about where this offending value might be. It's unfortunate we have to wait for Python 3 for chained exceptions, but the practice of reraising an exception as another one, including context, which then links to the original as the "cause", is an extremely common and useful practice - it's why Python 3 added it. Its unfortunate we disagree on this so I've added a mixin for you in r876ac91fd699 called DontWrapMixin. StatementError also displays the original exception class. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
