Re: Prefixing libpq error message with function names
От | Bruce Momjian |
---|---|
Тема | Re: Prefixing libpq error message with function names |
Дата | |
Msg-id | 200107121709.f6CH9BT13889@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Prefixing libpq error message with function names (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
> Most, or at least half, of the error messages that libpq itself generates > look like "PQwhatever(): this and that went wrong", where PQwhatever is > usually the function that generates the error message. > > I consider this practice ugly. If PQwhatever is an exported API function, > then the users knows perfectly well what function the message came from. > In fact, a common idiom is > > if (PQsomething() != OK) > fprintf(stderr, "PQsomething: %s", PQerrorMessage(conn)); > > which is obviously going to look funky. > > If PQwhatever is an internal function, then this practice is just plain > confusing to the user. In some cases the code tries to be smart and pass > in the name of "front line" API function, but this doesn't really end up > helping anybody. > > libpq is not complex and large enough that it would be tedious for a > developer to locate any given error message or derive the location in case > of a rare duplicate. (I understand that in the backend this premise does > not necessarily hold, but I'm only talking about libpq.) > > So would anyone object if I get rid of this while doing the i18n pass over > libpq? I vote it should be removed too. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: