Re: Adjust errorcode in background worker code - Mailing list pgsql-hackers

On 7 November 2015 at 02:55, Robert Haas <robertmhaas@gmail.com> wrote:

> I wonder if we need to think about inventing some new error codes.  I
> can sort of understand that "feature not supported" is something that
> can come in a large number of different contexts and mean pretty much
> the same all the time, but I'm betting that things like "invalid
> parameter value" and "invalid text representation" and "object not in
> prerequisite state" cover an amazing breadth of errors that may not
> actually be that similar to each other.

That depends on what client applications are going to do about the error.

If the app's only choice is likely to be "huh, that's weird, I'll barf
and tell the user about it" then there's little point changing
anything. The app just spits out a different error and nobody gains
anything.

If there are error sites where an application could take specific,
useful action in response to an error then they could well benefit
from being changed. ERRCODE_T_R_DEADLOCK_DETECTED for example is
extremely useful to applications.

So the first step should be auditing error sites of interest to see
whether the client app could possibly do anything constructive about
the error. Then see if there's an existing category it'd fit better,
or if we have a group of errors that would go well together in a new
category where the application action for them is similar.

Having too many highly specific errors is at least as bad as too few
broad categories. You land up with huge case statements and error
number lists - which you inevitably miss something from. They're
annoying to write, so they start getting re-used and cargo culted in
increasingly outdated forms. Next thing you know you've invented Java
exception handling ;)

Personally the only PostgreSQL errors I've ever cared about handling
specifically have been:

* deadlock detected, serialization failure for tx abort and retry loop
* connection-level errors, for reconnect and retry handling, graceful
reporting of DB shutdown, etc
* constraint violations, where useful info can be extracted to tell
the user what exactly was wrong with their input
* access permission errors, to drive more informative client-side UI

The great majority of sever-side errors go into the "huh, something's
broken that shouldn't have, tell the user to tell the admin" box.

I'm nuts about handling errors in my code compared to most of what
I've seen. The majority of apps I see aren't even prepared to cope
with a deadlock without data loss, tending to barf an error into the
logs and/or to the user, forget what they were doing, and hope someone
comes to rescue them or re-enter the info.

Do you think anyone has *ever* written code to trap
ERRCODE_AMBIGUOUS_FUNCTION or ERRCODE_INVALID_ARGUMENT_FOR_LOG?  Not
counting simple translation layers that map every exception ... I
doubt it.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services