Re: Why doesn't `RAISE EXCEPTION` provide error context?

On Thursday, April 2, 2015, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:

>
>
> 2015-04-02 9:13 GMT+02:00 David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com
> <javascript:_e(%7B%7D,'cvml','david(dot)g(dot)johnston(at)gmail(dot)com');>>:
>
>> Adding "raw" content present on Nabble that gets filtered by the mailing
>> list.
>>
>> On Wednesday, April 1, 2015, Taytay <taylor(at)youneedabudget(dot)com
>> <javascript:_e(%7B%7D,'cvml','taylor(at)youneedabudget(dot)com');>> wrote:
>>
>>> We make heavy use of `GET STACKED DIAGNOSTICS` to determine where errors
>>> happened.
>>> However, I am trying to use RAISE EXCEPTION to report errors, and have
>>> discovered that RAISE is specifically prevented from adding to the error
>>> context:
>>
>>
>> ----
>> static void
>> plpgsql_exec_error_callback(void *arg)
>> {
>> PLpgSQL_execstate *estate = (PLpgSQL_execstate *) arg;
>>
>> /* if we are doing RAISE, don't report its location */
>> if (estate->err_text == raise_skip_msg)
>> return;
>> ----
>>
>
> We talked more time about a change of this behave - the discus finished
> without end
>
>
> http://www.postgresql.org/message-id/CAFj8pRDFHqv7cKXP-K+uBzW6627HytT7bct4ZxDBseLXc1Rcgg@mail.gmail.com
>
> I am thinking, so current design is too simple and should be changed, and
> if will be a agreement I can add this patch to next commitfest.
>
> Regards
>
> Pavel
>
>
>>
>>
>>>
>>> So that means that this doesn't work:
>>>
>>>
>>>
>> RAISE EXCEPTION 'This exception will not get a stack trace';
>>
>> EXCEPTION WHEN others THEN
>>
>> -- If the exception we're catching is one that Postgres threw,
>> -- like a divide by zero error, then this will get the full
>> -- stack trace of the place where the exception was thrown.
>> -- However, since we are catching an exception we raised manually
>> -- using RAISE EXCEPTION, there is no context/stack trace!
>> GET STACKED DIAGNOSTICS v_error_stack = PG_EXCEPTION_CONTEXT;
>>
>>
>>> I've posted more details here:
>>>
>>> http://dba.stackexchange.com/questions/96743/postgres-how-to-get-stack-trace-for-a-manually-raised-exception
>>>
>>> That context would be awfully useful for us, even for manually generated
>>> exceptions.
>>> Can anyone shed some light on A) why this is, and B) if it's still
>>> desired,
>>> and C) if so, are there any workarounds? Is there an exception I can
>>> trick
>>> Postgres into throwing that will include my user-generated string?
>>>
>>> Many thanks for any help you can offer.
>>>
>>>
>>
>>
>
>
The OP on this thread has introduced a potential compromise. Keep the
current printing behavior for RAISE but the construction of the error
itself should contain all of the relevant detail so that the caller can get
to the suppressed information via, in this instance, GET STACKED
DIAGNOSTICS inside an exception handler - a situation where the error is in
context but has not yet been printed.

Giving the function author the ability, via a new using clause, to bypass
the printing short-circuit is another feature to consider.

I haven't fully comprehended the design decisions and trade-offs but
omitting data to facilitate printing doesn't sound like an appropriate
solution - not that I have any clue how hard it would be separate the two
aspects. Likewise with adding in a short-circuit that is judgemental
without providing some means to bypass it. We are not talking about data
integrity or performance here and while I'll admit reducing verbosity is a
valid goal mis-use of a provided work-around mechanic is not that serious a
transgression and one readily noticed and somewhat readily corrected.

David J.