On Sunday, May 8, 2022, Bryn Llewellyn <
bryn@yugabyte.com> wrote:
«
Note that ASSERT is meant for detecting program bugs, not for reporting ordinary error conditions. Use the RAISE statement, described above, for that.
»
But it takes quite a stretch of the imagination to infer that this means that the "assert_failure" exception cannot be handled.
Agreed. But as the pl/pgsql section “trapping errors” notes:
“The special condition name OTHERS matches every error type except QUERY_CANCELED and ASSERT_FAILURE. (It is possible, but often unwise, to trap those two error types by name.)”
i.e., you must trap it explicitly, not as part of others.
«
If no condition name nor SQLSTATE is specified in a RAISE EXCEPTION command, the default is to use ERRCODE_RAISE_EXCEPTION (P0001).
»
The spelling "errcode_raise_exception()" makes it look like a built-in function.
The fix I’d do is remove the “ERRCODE_” from the front of the name since that is an internal symbol that probably doesn’t even work in user code; the actual condition name is just the “raise_exception” part. That P0001 is simply the SQLSTATE for that name is perfectly clear to me and doesn’t warrant the verbosity of the proposal to avoid.
David J.
