SPI API and exceptions

SPI was invented before there was proper exception handling, so it
communicates errors by return values. This makes programming with SPI
either prone to errors of omission, or very ugly (ultimately, the
standard reasons why exceptions were invented).

So I was pondering whether we could introduce exceptions to SPI in some
way. I'm not sure how. We could invent an entirely separate set of
functions, or do some tricks in the header that things before
differently depending on some #define. Any ideas?

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> SPI was invented before there was proper exception handling, so it
> communicates errors by return values. This makes programming with SPI
> either prone to errors of omission, or very ugly (ultimately, the
> standard reasons why exceptions were invented).

> So I was pondering whether we could introduce exceptions to SPI in some
> way. I'm not sure how. We could invent an entirely separate set of
> functions, or do some tricks in the header that things before
> differently depending on some #define. Any ideas?

For practically all the nontrivial SPI functions, callers already have
to expect that exceptions can be thrown; just not for the specific
error causes called out as SPI return codes. So I wonder whether we
could get away with just converting all the SPI errors to elogs as well.
It would change them from specifically-handled errors into general-case
errors, but for many call sites that's no problem.

Note though that there are some cases where handling of "expected"
errors would get a lot more annoying if we made them into elogs;
for instance SPI_ERROR_NOATTRIBUTE from SPI_fnumber() and friends.
That particular case might be solvable by defining SPI_ERROR_NOATTRIBUTE
as InvalidAttrNumber. I think you'd need to go around and look at all
uses of each SPI_ERROR_XXX code before deciding that it's just dead
weight and should be converted to a generic exception.

regards, tom lane