2012-02-25 11:30:03 +04:00
|
|
|
import exceptions
|
|
|
|
|
2015-08-21 22:09:05 +03:00
|
|
|
|
2012-02-25 11:30:03 +04:00
|
|
|
class Error(exceptions.StandardError):
|
|
|
|
pass
|
|
|
|
|
2015-08-21 22:09:05 +03:00
|
|
|
|
2013-05-31 11:05:53 +04:00
|
|
|
class DatabaseError(exceptions.StandardError):
|
2012-02-25 11:30:03 +04:00
|
|
|
pass
|
|
|
|
|
2015-08-21 22:09:05 +03:00
|
|
|
|
2015-03-13 12:37:47 +03:00
|
|
|
class DataError(DatabaseError):
|
|
|
|
pass
|
|
|
|
|
2015-08-21 22:09:05 +03:00
|
|
|
|
2013-05-31 11:05:53 +04:00
|
|
|
class Warning(exceptions.StandardError):
|
2012-02-25 11:30:03 +04:00
|
|
|
pass
|
|
|
|
|
2015-08-21 22:09:05 +03:00
|
|
|
|
2013-05-31 11:05:53 +04:00
|
|
|
class InterfaceError(Error):
|
2012-02-25 11:30:03 +04:00
|
|
|
pass
|
|
|
|
|
2015-08-21 22:09:05 +03:00
|
|
|
|
2012-02-25 11:30:03 +04:00
|
|
|
class InternalError(DatabaseError):
|
|
|
|
pass
|
|
|
|
|
2015-08-21 22:09:05 +03:00
|
|
|
|
2012-02-25 11:30:03 +04:00
|
|
|
class OperationalError(DatabaseError):
|
|
|
|
pass
|
|
|
|
|
2015-08-21 22:09:05 +03:00
|
|
|
|
2012-02-25 11:30:03 +04:00
|
|
|
class ProgrammingError(DatabaseError):
|
|
|
|
pass
|
|
|
|
|
2015-08-21 22:09:05 +03:00
|
|
|
|
2013-05-31 11:05:53 +04:00
|
|
|
class NotSupportedError(ProgrammingError):
|
2012-02-25 11:30:03 +04:00
|
|
|
pass
|
|
|
|
|
2015-08-21 22:09:05 +03:00
|
|
|
|
2013-05-31 11:05:53 +04:00
|
|
|
class IntegrityError(DatabaseError):
|
2012-02-25 11:30:03 +04:00
|
|
|
pass
|
|
|
|
|
2015-08-21 22:09:05 +03:00
|
|
|
|
2013-05-31 11:05:53 +04:00
|
|
|
class PartialCommitError(IntegrityError):
|
2012-02-25 11:30:03 +04:00
|
|
|
pass
|
2014-01-23 05:41:47 +04:00
|
|
|
|
|
|
|
|
|
|
|
# Below errors are VT specific
|
|
|
|
|
2015-08-21 22:09:05 +03:00
|
|
|
|
2014-01-23 05:41:47 +04:00
|
|
|
# Retry means a simple and immediate reconnect to the same host/port
|
|
|
|
# will likely fix things. This is initiated by a graceful restart on
|
|
|
|
# the server side. In general this can be handled transparently
|
|
|
|
# unless the error is within a transaction.
|
|
|
|
class RetryError(OperationalError):
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
|
|
# This failure is "permanent" - retrying on this host is futile. Push the error
|
|
|
|
# up in case the upper layers can gracefully recover by reresolving a suitable
|
|
|
|
# endpoint.
|
|
|
|
class FatalError(OperationalError):
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
2015-08-21 22:09:05 +03:00
|
|
|
# This failure is operational in the sense that we must teardown the
|
|
|
|
# connection to ensure future RPCs are handled correctly.
|
2014-01-23 05:41:47 +04:00
|
|
|
class TimeoutError(OperationalError):
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
|
|
class TxPoolFull(DatabaseError):
|
|
|
|
pass
|
2014-08-26 22:41:53 +04:00
|
|
|
|
2015-09-29 04:26:28 +03:00
|
|
|
# TransientError is raised for an error that is expected to go away soon. These
|
|
|
|
# errors should be retried. Examples: when a client exceedes allocated quota on
|
|
|
|
# a server, or when there's a backlog of requests and new ones are temporarily
|
|
|
|
# being rejected.
|
|
|
|
class TransientError(DatabaseError):
|
2014-08-26 22:41:53 +04:00
|
|
|
pass
|
2014-08-28 03:54:13 +04:00
|
|
|
|
|
|
|
|
2015-09-29 04:26:28 +03:00
|
|
|
# TODO(aaijazi): These are deprecated. They will be replaced by TransientError.
|
2014-08-28 03:54:13 +04:00
|
|
|
# ThrottledError is raised when client exceeds allocated quota on the server
|
2015-02-04 20:32:33 +03:00
|
|
|
class ThrottledError(DatabaseError):
|
2014-08-28 03:54:13 +04:00
|
|
|
pass
|