Re: More on elog and error codes
От | Philip Warner |
---|---|
Тема | Re: More on elog and error codes |
Дата | |
Msg-id | 3.0.5.32.20010322161938.02a87a70@mail.rhyme.com.au обсуждение исходный текст |
Ответ на | Re: More on elog and error codes (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: More on elog and error codes
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-hackers |
At 23:24 21/03/01 -0500, Tom Lane wrote: >I've pretty much got to agree with Peter on both of these points. Damn. >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. I agree it's more likely, but most (all?) cases can be caught by the compiler. It's not ideal, but neither is having eight different versions of the same message. >>> 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. This is a problem, I agree - but a procedural one. We need to make registering messages easy. To do this, rather than having a central message file, perhaps do the following: - allow multiple message files (which can be processed to produce .h files). eg. pg_dump would have it's own pg_dump_messages.xxx file. - define a message that will assume it's first arg is really a format string for use in the "can't happen" classes, and which has the SQLCODE for 'internal error'. We do need some central control, but by creating module-based message files we can allocate number ranges easily, and we at least take a step down the path towards a both easy locale handling and a 'big book of error codes'. ---------------------------------------------------------------- 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 по дате отправления: