I've pretty much got to agree with Peter on both of these points.
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.
>> 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.
regards, tom lane