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(at)rhyme(dot)com(dot)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 |/