Plugin should be able to report an error and specify the error message for it
Some parts of this description may be obsolete
after work on WL#751 "Error message construction" is complete.
Tasks that this WL should solve:
1. Plugin should be able to report an error of with an arbitrary error message
in an arbitrary place. It'll go into SHOW WARNINGS (plugin will specify a
severity). The server will probably wrap it as "got an error 'XXXX' from plugin
'YYY'"
2. Plugin should be able to write an arbitrary text to the error log, with
specified severity, a server will probably wrap it as ... (see above)
3. A plugin needs to be able to provide localized versions of error messages,
similar to what server does. Probably, plugin will provide its errmsg.txt and
server will pick up the correct language automatically.
4. Storage engines return a storage engine error codes (this may be true for
other plugin types too), besides an error number storage engine needs to return
the context so that the server could generate an error message. Currently it's
handler::print_error(), but it's not sufficient, for example, if a storage
engine check constraints at COMMIT time, the server could not know the context
(of a unique constraint violation, for example, table name, key name, key
value). A possible solution - Error_context structure with all necessary fields,
handler::print_error is changed to handler::fill_error_context, print_error is
moved out of handler class, on any error the storage engine fills the context
(the server does it when it can, otherwise the storage engine is responsible for
the job), then print_error(Error_context *) prints it. (big if() block in
ha_delete_table() should be rewritten when this is done)
5. As a part of this WL a clear guidelines should be written to explain when and
how a plugin should use each of the error reporting mechanisms - when a method
#1, when #2, and when #4.
6. when 3) is done handler's error messages (see ha_init_errors() in handler.cc)
should be moved to its own errmsg.sys
7. monty wants to remove trivial (1:1) mapping from handler::print_error(). For
example, HA_ERR_OLD_FILE => ER_OLD_KEYFILE. And return HA_ERR_OLD_FILE directly
to the client. I (Sergei) am skeptical about it - it's a change in the
client-server API.
An error reporting service could look like
enum severity_level {ERROR, WARNING, INFORMATION};
struct Error_Reporting_Service {
/* i18n support: load/unload plugin's own errmsg.sys */
int (*load_messages)();
int (*unload_messages)();
/* convert an error code to the error message */
char *(*ER)(int code);
/* send an error back to the user */
int (*send)(char *plugin, int code, int level, const char *format, ...);
/* write a message to the log */
int (*log)(char *plugin, int level, const char *format, ...);
} Error_Reporting_Service;
Alternatively, i18n could be moved to a separate service.
You must be logged in to tag this worklog