Severity classifies a SQL Server message by operational impact. Levels 0–10 are informational rather than errors; level 10 is reported as level 0 for compatibility. Levels 11–16 describe errors a user can usually correct, including syntax, object-name, permission, and deadlock problems. Levels 17–19 generally require an administrator, while levels 20–24 are fatal, such as database or media corruption. section 7.1
Use severity to choose an error-handling response:
- Treat levels 0–10 as messages: execution continues because they are informational. section 7.1
- Handle levels 11–19 with TRY..CATCH. These severities transfer execution to the CATCH block, where transaction rollback and a meaningful error can be issued. section 7.1
- Do not rely on CATCH for severity 20 or higher. Fatal errors can make continued handling pointless because the connection may be closed. section 7.1
- Plan operational attention for levels 19–24, which are written to the error log; unattended processes may also need alerts for raised errors. section 7.1 section 7.7
A duplicate sales order is a level-16 problem
A duplicate primary-key insertion reports level 14, placing it among user-correctable errors. A procedure can catch that failure, roll back the transaction, and raise a clearer custom message such as “A duplicate sales order has been entered.” THROW can rethrow an original error or raise a custom number, message, and state, but its severity is always 16 and it cannot use a message stored in sys.messages. RAISERROR() supports custom messages and severity selection. section 7.1 section 7.1 section 7.1
A practical rule is to distinguish a recoverable application or input failure from an administrative condition and from a fatal failure. Pair severity-aware TRY..CATCH handling with transaction rollback, useful messages, logging, and alerting rather than assuming every error can be safely processed in the same way. section 7.1 section 7.7
