Re: More on elog and error codes
От | Philip Warner |
---|---|
Тема | Re: More on elog and error codes |
Дата | |
Msg-id | 3.0.5.32.20010321094352.0287ad00@mail.rhyme.com.au обсуждение исходный текст |
Ответ на | Re: More on elog and error codes (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: More on elog and error codes
(Philip Warner <pjw@rhyme.com.au>)
Re: More on elog and error codes (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
At 17:35 20/03/01 +0100, Peter Eisentraut wrote: >Philip Warner writes: > >> elog(CACHELOOKUPFAIL, cacheItemThatFailed); > >The disadvantage of this approach, which I tried to explain in a previous >message, is that we might want to have different wordings for different >occurences of the same class of error. > >Additionally, the whole idea behind having error *codes* is that the >client program can easily distinguish errors that it can handle specially. >Thus the codes should be numeric or some other short, fixed scheme. In >the backend they could be replaced by macros. This seems to be just an argument for constructing the value of PGERR_CACHELOOKUPFAIL carefully (which is what the VMS message source files did). The point is that when they are used by a developer, they are simple. >#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", ...) > I can appreciate that there may be cases where the same message is reused, but that is where parameter substitution comes in. 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? 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, ...) 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. Finally, if you do want to have some kind of error classification beyond the SQL code, it could be encoded in the error message file. ---------------------------------------------------------------- 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 |/
В списке pgsql-hackers по дате отправления: