On 22 июн, 17:48, Michael Bayer <mike...@zzzcomputing.com> wrote: > 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.
Excellent, thank you! -- Anton -- 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.
