|  | 
|  | BadQuery (const char *w="", int e=0) | 
|  | Create exception object.  More... 
 | 
|  | 
|  | BadQuery (const std::string &w, int e=0) | 
|  | Create exception object.  More... 
 | 
|  | 
| int | errnum () const | 
|  | Return the error number corresponding to the error message returned by what()  More... 
 | 
|  | 
|  | Exception (const Exception &e) MAY_THROW() | 
|  | Create exception object as copy of another. 
 | 
|  | 
| Exception & | operator= (const Exception &rhs)  throw () | 
|  | Assign another exception object's contents to this one. 
 | 
|  | 
|  | ~Exception ()  throw () | 
|  | Destroy exception object. 
 | 
|  | 
| virtual const char * | what () const  throw () | 
|  | Returns explanation of why exception was thrown. 
 | 
|  | 
Exception thrown when the database server encounters a problem while processing your query. 
Unlike most other MySQL++ exceptions, which carry just an error message, this type carries an error number to preserve Connection::errnum()'s return value at the point the exception is thrown. We do this because when using the Transaction class, the rollback process that occurs during stack unwinding issues a query to the database server, overwriting the error value. This rollback should always succeed, so this effect can fool code that relies on Connection::errnum() into believing that there was no error.
Beware that in older versions of MySQL++, this was effectively the generic exception type. (This is most especially true in v1.7.x, but it continued to a lesser extent through the v2.x series.) When converting old code to new versions of MySQL++, it's therefore possible to get seemingly "new" exceptions thrown, which could crash your program if you don't also catch a more generic type like mysqlpp::Exception or std::exception.