SQLEXCEPTION is one of three predefined condition names (SQLWARNING, NOT FOUND, SQLEXCEPTION) that you can reference when declaring an error handler inside a MySQL or MariaDB stored procedure, function, trigger, or event. Whereas SQLWARNING captures warnings (SQLSTATE classes starting with '01') and NOT FOUND captures the no-data condition (SQLSTATE '02000'), SQLEXCEPTION matches every other non-successful SQLSTATE—that is, any error that would normally cause statement failure. A handler declared for SQLEXCEPTION fires when the first statement that follows the DECLARE section raises an error. Depending on the handler type (EXIT, CONTINUE, or UNDO), control either leaves the stored routine, continues after the failing statement, or rolls back work done in the compound statement (UNDO is only supported in DB2). Typical uses include rolling back a transaction, logging the error information, or converting the error to a custom SQLSTATE via SIGNAL. SQLEXCEPTION works only inside compound statements (BEGIN … END) of stored programs and cannot be used in plain SQL scripts executed outside those contexts.
MySQL 5.0 (initial stored procedure support)
SQLWARNING handles SQLSTATE codes starting with '01' (warnings), NOT FOUND handles '02000' (no data), and SQLEXCEPTION catches all other error codes, making it a general error handler.
No. The handler merely intercepts the error. You must issue ROLLBACK explicitly inside the handler or rely on autocommit to undo changes.
Yes. You can have specific SQLSTATE or condition handlers first and add a SQLEXCEPTION handler as a fallback. The most specific matching handler is executed.
No. SQLEXCEPTION (and DECLARE HANDLER in general) can only be used inside stored procedures, functions, triggers, or events.