Re: The P0004 assert_failure exception assert_failure exception seems to be unhandleable
| От | David G. Johnston |
|---|---|
| Тема | Re: The P0004 assert_failure exception assert_failure exception seems to be unhandleable |
| Дата | |
| Msg-id | CAKFQuwan=zZDzyE4uL5n+FT3nQS2zE=Eixh7suxQg9xy7LkfdQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | The P0004 assert_failure exception assert_failure exception seems to be unhandleable (Bryn Llewellyn <bryn@yugabyte.com>) |
| Ответы |
Re: The P0004 assert_failure exception assert_failure exception seems to be unhandleable
|
| Список | pgsql-general |
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.
В списке pgsql-general по дате отправления: