Re: The P0004 assert_failure exception assert_failure exception seems to be unhandleable

On Sunday, May 8, 2022, Bryn Llewellyn <bryn(at)yugabyte(dot)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.