On 2 April 2015 at 19:15, Taylor Brown <tay...@youneedabudget.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.
