Re: More on elog and error codes
От | Peter Eisentraut |
---|---|
Тема | Re: More on elog and error codes |
Дата | |
Msg-id | Pine.LNX.4.30.0103212158370.1694-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: More on elog and error codes (Philip Warner <pjw@rhyme.com.au>) |
Ответы |
Re: More on elog and error codes
|
Список | pgsql-hackers |
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? How can this be checked against bugs? (I know GCC can be pretty helpful here, but does it catch all problems?) Conversely, when you look at the error message you don't know from what contexts it's called. The error messages will degrade rapidly in quality because changing one will become a major project. > 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. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
В списке pgsql-hackers по дате отправления: