MARK CALLAGHAN wrote:
> I want to return an error in the patch I submitted for
> This document appears to be out of date:
> How do I return an error for a SQL command? There is my_message,
> my_error, my_printf_error and push_warning in MySQL source. Most of
> these are not described by the URL above.
To raise an error:
MYF(0), sql_field->field_name, MAX_FIELD_CHARLENGTH);
To raise a warning:
If you use code starting in 5.5, you may look at THD::raise_error() and
Things to avoid (and yes, there are plenty of bad examples in the code):
- "ER_XXX, "plain text" --> should be ER_XXX, ER(ER_XXX), and the text
should be in errmsg.txt
- printf in buffer + "ER_XXX, buffer" --> likewise
- push_warning / push_warning_printf with a level of WARN_LEVEL_ERROR:
that's a bug.
Now, the real issue is if you want to return a *new* error.
This area, and the process around it to allow everybody to change the
code while keeping compatibility between releases (and have the same
error numbers for the same thing) is a major pain point, still unresolved.
Below is the procedure used by development:
The first step is to add an entry in the file sql/share/errmsg.txt, at
This is important so that the message text is not hard coded in the
source, and can be translated for other languages.
eng "RESIGNAL when handler not active"
"0K000" is optional, it's the SQLSTATE for this error.
Errors should be named ER_XXX, warnings WARN_XXX (not always followed).
The next question is whether the message contains printf-like parameters
When using %s parameters, please consider a max size like "%-.64s"
instead of just "%s" to protect from overflows when printing the message
with bad data.
This is for releases that are not GA yet, since creating new error codes
has no impact on existing applications.
For code already GA, if you follow this, then it will create merge
issues between your errmsg.txt and mysql errmsg.txt, and create
conflicts with error numbering later, which is why the generic
ER_UNKNOWN_ERROR + hard coded message text is suggested.
Keep in mind that even if conflicts may not visible now, they will
happen at the next upgrade, so this area is sensitive.
For new errors, to maintain compatibility, the choices are then limited to:
"Some error text here, without parameters",
"Some error text here, with the '%-.64s' parameter value"
ER_UNKNOWN_ERROR, "Some warning text here, without parameters");
ER_UNKNOWN_ERROR, "Some warning text here, with the '%-.64s'
There are still several problems here:
- the text is hard coded again (no hope of translation),
- there is only 1 error code to choose from, which makes it hard for an
application to sort things out if several enhancements needs new errors
for different things, and if a client / stored procedure needs special
logic based on the error *code* (as opposed to a human looking at the
All this is only a work around, if there is no existing error message
from errmsg.txt that can be reused, so the best hope is to find a "close
enough" existing message :(