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

On 2 April 2015 at 19:15, Taylor Brown <taylor(at)youneedabudget(dot)com> wrote:

> So, I would rather put a check like this at the top of my function:
>
> --
> important_variable = (p_request::json->>'important_variable')::integer;
> IF (important_variable is NULL) THEN RAISE EXCEPTION 'important_variable
> must not be NULL.'; END IF;
> --
>
> But I won't be able to get the context for that exception, and all I'll be
> able to return from the function or write to the logs is
> 'important_variable must not be NULL.'. If that's the only place I throw
> that error, I'll know where to look. Otherwise, I have no context, and
> won't be able to determine where my exception was thrown. So I'm actually
> better off _not_ throwing my own custom exceptions, even though I would
> prefer to be more defensive about this sort of thing in my code.
>
> I thought I might be able to "trick" postgres into throwing another
> unrelated exception that would not only include my custom error message,
> but allow me to extract the context, telling me the function where I should
> begin debugging.
>

Just a quick idea, but... Perhaps you could put a constraint on those JSON
messages indirectly, by mapping it to some kind of template table?
The top-level of a JSON message can usually be mapped to a table, and a
table can have constraints and, for example, a BEFORE INSERT trigger that
always returns NULL so that the data is not actually inserted into the
table.

--
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.