Tom Lane schrob:
> Andreas Seltenreich <andreas+pg@gate450.dyndns.org> writes:
>> Tom Lane schrob:
>>> It *might* work to put a generic "catch/report via elog" handler around
>>> each one of your entry-point functions. Haven't tried it.
>
>> Hmm, this setup worked quite stable here for some smaller educational
>> projects. The snippet I used to wrap the C++ was:
>> [ snip ]
>> [ some later mention of calling back into the backend for, eg, palloc ]
>
> I was with you until that last bit. Have you covered the case where
> palloc or another called-back backend routine throws an elog? AFAICS
Not at all. It wasn't necessary in my case, since my classes were
mostly mathematical abstractions, and the only resource held was
memory via the allocator template, which got garbage collected anyway
on a "c-exception". But I see that supporting the other way round is a
must-have as soon as you hog other kinds of resources with C++.
> the only clean way to do that is to PG_TRY around every such call,
> throw the error as a C++ throw, catch it again at the function exit
> level, re-throw as a PG longjmp :-(. Aside from the sheer tedium and
How about letting preprocessor magic wrap calls to the backend with a
PG_TRY and an appropriate throw() if __cplusplus is defined for a
start?
> error-proneness, there's the certainty of losing quite a lot of semantic
> detail in the error reports.
Durr, as long as one inherits the exception class from std::exception
for a proper e.what() interface I don't see a way how semantics could
be lost (using automated throwing with the preprocessor magic
mentioned above that is).
> And on top of that, what if the error was one that the backend can't
> recover from except by a transaction abort? If some level of the C++
> code thinks it can catch and recover from the error, you've left
> things in a pretty bad state.
Hmm, but if you replace "C++" with "C" and "catch" with "PG_TRY" in
that sentence, wouldn't that be business as usual?
Thanks,
Andreas
