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

At 23:56 19/03/01 +0100, Peter Eisentraut wrote:
>
>Essentially, I envision making up a new function, say "elogc", which has
>
>    elogc(<level>, [<subsys>,?] <code>, message...)
>
>where the code is some macro, the expansion of which is to be determined.
>A call to "elogc" would also require a formalized message wording, adding
>the error code to the documentation, which also requires having a fairly
>good idea how the error can happen and how to handle it.  This could
>perhaps even be automated to some extent.
>
>All the calls that are not converted yet will be assigned a to the generic
>"internal error" class; most of them will stay this way.
>
...
>
>So we need some good error numbering scheme.  Any ideas?
>

FWIW, the VMS scheme has error numbers broken down to include system,
subsystem, error number & severity. These are maintained in an error
message source file. eg. the file system's 'file not found' error message
is something like:

FACILITY RMS (the file system)
...
SEVERITY WARNING
...
FILNFND "File %AS not found"
...

It's a while since I used VMS messages files regularly, this is at least
representative. It  has the drawback that severity is often tied to the
message, not the circumstance, but this is a problem only rarely.

In code, the messages are used as external symbols (probably in our case
representing pointers to C format strings). In making extensive use of such
a mnemonics, I never really needed to have full text messages. Once a set
of standards is in place for message abbreviations, the most people can
read the message codes. This would mean that:
   elogc(<level>, [<subsys>,?] <code>, message...)

becomes:
   elogc(<code> [, parameter...])

eg.
   "cache lookup of %s failed"

might be replaced by:
   elog(CACHELOOKUPFAIL, cacheItemThatFailed);

and    "internal error: %s"

becomes
   elog(INTERNAL, "could not find the VeryImportantThing");

Unlike VMS, it's probably a good idea to separate the severity from the
error code, since a  CACHELOOKUPFAIL in one place may be less significant
than another (eg. severity=debug).

I also think it's important that we get the source file and line number
somewhere in the message, and if we have these, we may not need the subsystem.



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