Prefixing libpq error message with function names

Started by Peter Eisentrautover 24 years ago3 messages
#1Peter Eisentraut
peter_e@gmx.net

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?

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

#2Bruce Momjian
pgman@candle.pha.pa.us
In reply to: Peter Eisentraut (#1)
Re: Prefixing libpq error message with function names

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, Pennsylvania 19026
#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Peter Eisentraut (#1)
Re: Prefixing libpq error message with function names

Peter Eisentraut <peter_e@gmx.net> writes:

So would anyone object if I get rid of this while doing the i18n pass over
libpq?

Don't forget to fix the numerous places where examples of these messages
appear in the documentation ...

regards, tom lane