Re: More on elog and error codes

At 23:24 21/03/01 -0500, Tom Lane wrote:
>I've pretty much got to agree with Peter on both of these points.

Damn.


>Philip Warner <pjw@rhyme.com.au> writes:
>> At 22:03 21/03/01 +0100, Peter Eisentraut wrote:
>>>>> elogc(ERROR, PGERR_FUNCNOTYPE, ...)
>>> 
>>> This is going to be a disaster for the coder.  Every time you look at an
>>> elog you don't know what it does? Is the first arg a %s or a %d?  What's
>>> the first %s, what the second?
>
>>> From experience using this sort of system, probably 80% of errors in new
>> code are new; if you don't know the format of your own errors, then you
>> have a larger problem. Secondly, most errors have obvious parameters, and
>> it only ever gets confusing when they have more than one parameter, and
>> even then it's pretty obvious.
>
>The general set of parameters might be pretty obvious, but the exact
>type that the format string expects them to be is not so obvious.  We
>have enough ints, longs, unsigned longs, etc etc running around the
>system that care is required.  If you look at the existing elog calls
>you'll find quite a lot of explicit casts to make certain that the right
>thing will happen.  If the format strings are not directly visible to
>the guy writing an elog call, then errors of that kind will creep in
>more easily.

I agree it's more likely, but most (all?) cases can be caught by the
compiler. It's not ideal, but neither is having eight different versions of
the same message.


>>> The error messages will degrade rapidly in quality
>>> because changing one will become a major project.
>
>> Changing one will be a major project only if it is used everywhere.
>
>I agree with Peter on this one too.  Even having to edit a separate
>file will create enough friction that people will tend to use an
>existing string if it's even marginally appropriate.  What I fear even
>more is that people will simply not code error checks, especially for
>"can't happen" cases, because it's too much of a pain in the neck to
>register the appropriate message.
>
>We must not raise the cost of adding error checks significantly, or we
>will lose the marginal checks that sometimes save our bacon by revealing
>bugs.

This is a problem, I agree - but a procedural one. We need to make
registering messages easy. To do this, rather than having a central message
file, perhaps do the following:

- allow multiple message files (which can be processed to produce .h
files). eg. pg_dump would have it's own pg_dump_messages.xxx file.

- define a message that will assume it's first arg is really a format
string for use in the "can't happen" classes, and which has the SQLCODE for
'internal error'.

We do need some central control, but by creating module-based message files
we can allocate number ranges easily, and we at least take a step down the
path towards a both easy locale handling and a 'big book of error codes'.


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/