From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Badly designed error reporting code in controldata_utils.c |
Date: | 2016-03-07 16:02:45 |
Message-ID: | 56DDA625.8020709@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 03/06/2016 07:34 PM, Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>> On 03/06/2016 05:47 PM, Tom Lane wrote:
>>> That's much better, but is there a reason you're using exit(2)
>>> and not exit(EXIT_FAILURE) ?
>
>> Only because I was trying to stick with what was originally in
>> src/bin/pg_controldata/pg_controldata.c
>
> Meh. It looks to me like the standard way to handle this
> for code in src/common/ is exit(EXIT_FAILURE).
I have no issue with using EXIT_FAILURE, but note:
1) That will change the exit error from the previous value of 2 to 1 for
pg_controldata
2) There are many examples in other parts of the source that do not use
EXIT_FAILURE, and even in src/common:
8<-------------
grep -rnE "exit\(EXIT_FAILURE\)" src/common/* --include=*.c
src/common/fe_memutils.c:36: exit(EXIT_FAILURE);
src/common/fe_memutils.c:76: exit(EXIT_FAILURE);
src/common/fe_memutils.c:93: exit(EXIT_FAILURE);
src/common/fe_memutils.c:99: exit(EXIT_FAILURE);
src/common/psprintf.c:135: exit(EXIT_FAILURE);
src/common/psprintf.c:182: exit(EXIT_FAILURE);
grep -rnE "exit\((1|2)\)" src/common/* --include=*.c
src/common/restricted_token.c:187: exit(1);
src/common/username.c:86: exit(1);
8<-------------
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-03-07 16:09:22 | Re: WIP: Upper planner pathification |
Previous Message | Robert Haas | 2016-03-07 15:37:18 | Re: WIP: Upper planner pathification |