PEP 249 exceptions: support DatabaseError subclasses whenever possible

[fdcastel]

From PEP 249:

DataError
Exception raised for errors that are due to problems with the processed data like division by zero, numeric value out of range, etc.

IntegrityError
Exception raised when the relational integrity of the database is affected, e.g. a foreign key check fails.

InternalError
Exception raised when the database encounters an internal error, e.g. the cursor is not valid anymore, the transaction is out of sync, etc.

ProgrammingError
Exception raised for programming errors, e.g. table not found or already exists, syntax error in the SQL statement, wrong number of parameters specified, etc.

NotSupportedError
Exception raised in case a method or database API was used which is not supported by the database, e.g. requesting a .rollback() on a connection that does not support transaction or has transactions turned off.

[fdcastel]

Rationale: SQLAlchemy can use these more specific exceptions.

[pcisar]

Well, the problem is that firebird-driver does not know the exact cause for the error that is reported by Firebird OO API. The OO API reports error via Status that is part of all API calls. firebird-driver uses simple handling (for speed) that checks the Status and is there is an error, it raises exception with information taken from status. To provide any specific exception, firebird-driver will must implement some deeper analysis of Status error data and mapping to specific exceptions. Quite a lot of work + burden to maintain up to date.