MySQL++ Reference Manual

MySQL++: mysqlpp::BadQuery Class Reference

MySQL++ 3.3.0

Public Member Functions | List of all members
mysqlpp::BadQuery Class Reference

Exception thrown when the database server encounters a problem while processing your query. More...

`#include <exceptions.h>`

Inheritance diagram for mysqlpp::BadQuery:
[legend]
Collaboration diagram for mysqlpp::BadQuery:
[legend]

## Public Member Functions
| 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...
Public Member Functions inherited from mysqlpp::Exception
| 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.

## Additional Inherited Members
Protected Member Functions inherited from mysqlpp::Exception
| Exception (const char *w="") throw ()
| Create exception object.
| Exception (const std::string &w) throw ()
| Create exception object.
Protected Attributes inherited from mysqlpp::Exception
std::string | what_
| explanation of why exception was thrown

## Detailed Description

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.

## Constructor & Destructor Documentation

## ◆ BadQuery() [1/2]

mysqlpp::BadQuery::BadQuery | ( | const char * | w = `""`,
|  | int | e = `0`
| ) |  |
| inlineexplicit

Create exception object.

Parameters

  w | explanation for why the exception was thrown
  e | the error number from the underlying database API

## ◆ BadQuery() [2/2]

mysqlpp::BadQuery::BadQuery | ( | const std::string & | w,
|  | int | e = `0`
| ) |  |
| inlineexplicit

Create exception object.

Parameters

  w | explanation for why the exception was thrown
  e | the error number from the underlying database API

## Member Function Documentation

## ◆ errnum()

int mysqlpp::BadQuery::errnum | ( |  | ) | const
| inline

Return the error number corresponding to the error message returned by what()

This may return the same value as Connection::errnum(), but not always. See the overview documentation for this class for the reason for the difference.

The documentation for this class was generated from the following file:

- exceptions.h