From: | Dave Page <dpage(at)pgadmin(dot)org> |
---|---|
To: | Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com> |
Cc: | pgadmin-hackers(at)postgresql(dot)org |
Subject: | Re: pgAdmin III commit: Revert the previous change that introduced sysSetti |
Date: | 2011-02-18 16:48:57 |
Message-ID: | AANLkTikFAPXBH6BnRJ5O356uoT3iE1sY9Q6JHwdkm5dW@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
On Fri, Feb 18, 2011 at 2:50 PM, Peter Geoghegan
<peter(dot)geoghegan86(at)gmail(dot)com> wrote:
> Uh, it just occurred to me that without exceptions, there is no
> compelling way to report a failure from Read() variants. Qt does
> things like returning default constructed variables, that have values
> of 0 in the event of a failure. What do you think of that? Failures
> presumably more or less never occur with Read() overloads as things
> stand.
We generally do the same (the Read() functions tend to take a third
parameter containing the default value to return). But, returning an
error isn't a problem - we pass the value we read back in a reference
passed as a parameter, and can return true or false to indicate error
or success.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2011-02-18 18:01:56 | Re: pgAdmin III commit: Revert the previous change that introduced sysSetti |
Previous Message | Dave Page | 2011-02-18 16:46:53 | Re: pgAdmin III commit: Revert the previous change that introduced sysSetti |