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:
diff -r 8f070bce386b lib/sqlalchemy/engine/base.py
--- a/lib/sqlalchemy/engine/base.py Tue Jun 21 18:34:14 2011 -0400
+++ b/lib/sqlalchemy/engine/base.py Wed Jun 22 09:39:05 2011 +0200
@@ -1689,6 +1689,10 @@
parameters,
cursor,
context):
+ if isinstance(e, exc.SQLAlchemyError):
+ # don't suppress or reraise already handled exceptions
+ return
+
if getattr(self, '_reentrant_error', False):
# Py3K
#raise exc.DBAPIError.instance(statement, parameters, e,
I then just derive my custom exception classes from
sqlalchemy.exc.SQLAlchemyError and everyone is happy. What do you
think?
--
Anton
>
>
> > --
> > Anton
>
> >> On Jun 21, 2011, at 6:39 PM, an...@angri.ru wrote:
>
> >>> Hi,
>
> >>> I'm porting sqlamp [1] to SQLAlchemy 0.7 and have some difficulties
> >>> with it. One of them is raising an exception (non-DBAPI) from
> >>> process_bind_param() method of classes derived from TypeDecorator. In
> >>> 0.6 [2] method _handle_dbapi_exception() of engine.base.Connectable
> >>> doesn't munch the exception if it is not an instance of
> >>> self.dialect.dbapi.Error. 0.7 in turn does [3]. And it reraises the
> >>> exception of different type - instead of the original one it uses
> >>> DBAPIError.instance(), which in my case returns StatementError. How
> >>> can I fix it on my side?
>
> >>> Thanks.
>
> >>> --
> >>> Anton
>
> >>> [1]http://sqlamp.angri.ru
> >>> [2]http://www.sqlalchemy.org/trac/browser/lib/sqlalchemy/engine/base.py?...
> >>> [3]http://www.sqlalchemy.org/trac/browser/lib/sqlalchemy/engine/base.py?...
>
> >>> --
> >>> 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
> >>> athttp://groups.google.com/group/sqlalchemy?hl=en.
>
> > --
> > 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
> > athttp://groups.google.com/group/sqlalchemy?hl=en.
--
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.
