On Sunday, May 8, 2022, Bryn Llewellyn <b...@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.
