Re: More on elog and error codes - Mailing list pgsql-hackers

At 22:03 21/03/01 +0100, Peter Eisentraut wrote:
>Philip Warner writes:
>
>> If the motivation behind this is to alloy easy translation to SQL error
>> codes, then I suggest we have an error definition file with explicit
>> translation:
>>
>> Code             SQL   Text
>> PGERR_TYPALREXI  02xxx "type %s cannot be created because it already
exists"
>> PGERR_FUNCNOTYPE 02xxx "type %s used as argument %d of function %s doesn't
>> exist"
>>
>> and if we want a generic 'type does not exist', then:
>>
>> PGERR_NOSUCHTYPE 02xxx "type %s does not exist - %s"
>>
>> where the %s might contain 'it can't be used as a function argument'.
>>
>> the we just have
>>
>> elogc(ERROR, PGERR_TYPALEXI, ...)
>>
>> /* elsewhere... */
>>
>> 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. This concern was often raised by people new
to the system, but generally turned out to be more FUD than fact.


>How can this be checked against bugs? 
>Conversely, when you look at the error message you don't know from what
>contexts it's called.

Am I missing something here? The user gets a message like: 
   TYPALREXI: Specified type 'fred' already exists.

then we do 
   glimpse TYPALREXI

It is actually a lot easier than the plain text search we already have to
do, when we have to guess at the words that have been substituted into the
message. Besides, in *both* proposed systems, if we have done things
properly, then the postgres log also contains the module name & line #.


>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. Most
will be relatively localized. And, with glimpse 'XYZ', it's not really that
big a task. Finally, you would need to ask why it was being changed - would
a new message work better? Tell me where the degradation in quality is in
comparison with text-in-the-source versions, with umpteen dozen slightly
different versions of essentially the same error messages?


>> Creating central message files/objects has the added advantage of a much
>> simpler locale support - they're just resource files, and they're NOT
>> embedded throughout the code.
>
>Actually, the fact that the messages are in the code, where they're used,
>and not in a catalog file is a reason why gettext is so popular and
>catgets gets laughed at.

Is there a URL for a getcats vs. gettext debate would help me understand
the reason for the laughter? I can understand laughing at code that looks
like:
   elog(ERROR, 123456, typename);

but
   elog(ERROR, TYPALREXI, typename);

is a whole lot more readable.


Also, you failed to address the two points below:

>#define PGERR_TYPE 1854
>
>/* somewhere... */
>
>elogc(ERROR, PGERR_TYPE, "type %s cannot be created because it already
exists", ...)
>
>/* elsewhere... */
>
>elogc(ERROR, PGERR_TYPE, "type %s used as argument %d of function %s
doesn't exist", ...)
>

In the specific example above, returning the same error code is not going
to help the client. What if they want to handle "type %s used as argument
%d of function %s doesn't exist" by creating the type, and silently ignore
"type %s cannot be created because it already exists"?

How do you handle "type %s can not be used as a function return type"? Is
this PGERR_FUNC or PGERR_TYPE?



----------------------------------------------------------------
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   |/