Re: try/catch macros for Postgres backend

Tom Lane wrote:
> In service of the refactoring of error handling that I was talking about
> a few days ago, I'm finding that there are several places that really
> ought to catch longjmps and clean up after themselves, instead of
> expecting that whatever mess they've made will be cleaned up for them
> when control gets back to PostgresMain().


This is especially a problem when the cleanup needs to be done inside 
the embedded interpreter. I found that with R, I had to throw an error 
in the R interpreter in order to allow the interpreter to clean up its 
own state. That left me with code like this:

8<--------------------  /*   * trap elog/ereport so we can let R finish up gracefully   * and generate the error once
weexit the interpreter   */  memcpy(&save_restart, &Warn_restart, sizeof(save_restart));  if (sigsetjmp(Warn_restart,
1)!= 0)  {    InError = false;    memcpy(&Warn_restart, &save_restart, sizeof(Warn_restart));    error("%s", "error
executingSQL statement");  }
 
  [...(execute query via SPI)...]
8<--------------------

The error() call throws the R intepreter error directly, so that on exit 
from the R function call I do this:

8<--------------------  ans = R_tryEval(call, R_GlobalEnv, &errorOccurred);
  if(errorOccurred)  {    ereport(ERROR,...
8<--------------------


> Does anyone have a problem with this macro syntax?  The try/catch names
> are stolen from Java, so I'm figuring they won't terribly surprise any
> modern programmer, but I'm open to different names if anyone has a
> better idea.

Looks good to me, but I worry about being able to do what I've described 
above. Basically I found that if I don't allow R to clean up after 
itself by propagating the SPI call generated error into R, before 
throwing a Postgres ERROR, I wind up with core dumps. Or am I just doing 
something wrong here (it seems to work for all of the test cases I could 
think of)?

Joe