delta/python-packages/sqlalchemy.git/lib/sqlalchemy/exc.py, branch pr/146

- Exception messages have been spiffed up a bit. The SQL statement

2014-10-17T23:37:45+00:00

and parameters are not displayed if None, reducing confusion for
error messages that weren't related to a statement.  The full
module and classname for the DBAPI-level exception is displayed,
making it clear that this is a wrapped DBAPI exception.  The
statement and parameters themselves are bounded within a bracketed
sections to better isolate them from the error message and from
each other.
fixes #3172

- the test_except test was doing an unnecessary workaround of some kind,

2014-10-12T23:37:14+00:00

take that out, restore the better exception logic in exc

- roll back part of pr 140 to get exception wrapping working again

2014-10-12T13:54:44+00:00

cleanup exception handling - use new exception hierarchy (since python 2.5)

2014-10-02T20:00:31+00:00

- The exception wrapping system for DBAPI errors can now accommodate

2014-07-29T18:06:43+00:00

non-standard DBAPI exceptions, such as the psycopg2
TransactionRollbackError.  These exceptions will now be raised
using the closest available subclass in ``sqlalchemy.exc``, in the
case of TransactionRollbackError, ``sqlalchemy.exc.OperationalError``.
fixes #3075

PEP8 style fixes

2014-07-14T00:10:55+00:00

- break up the copyright comment as part of a pass

2014-07-09T22:26:55+00:00

to get all flake8 passing

- implement kwarg validation and type system for dialect-specific

2014-01-19T00:26:56+00:00

arguments; [ticket:2866]
- add dialect specific kwarg functionality to ForeignKeyConstraint, ForeignKey

- happy new year

2014-01-05T21:57:05+00:00

- The :class:`.exc.StatementError` or DBAPI-related subclass

2013-12-11T19:30:18+00:00

now can accomodate additional information about the "reason" for
the exception; the :class:`.Session` now adds some detail to it
when the exception occurs within an autoflush.  This approach
is taken as opposed to combining :class:`.FlushError` with
a Python 3 style "chained exception" approach so as to maintain
compatibility both with Py2K code as well as code that already
catches ``IntegrityError`` or similar.