On 9/6/06, Kamesh Jayachandran <kamesh@collab.net> wrote:
>
>
>
> We have SQLITE_ROW too.
Which again, is an incredibly small number of users.
There are 37 uses of SQLITE_ERR because of SQLITE_OK.
The number of places we need to error check because of SQLITE_DONE is 4
The number of places we need to error check because of SQLITE_ROW is 2
(there are 4 total uses, 2 of which are checks for errors).
Modifying 37 instances of a macro to take an extra argument because of
6 lines of code could use it is not a good idea.
> Initially thought the same, but after seeing SQLITE_ROW, I preferred to
> have a single macro and hence the patch.
I simply disagree that a single macro is the right thing here. If
something needs slightly different semantics, it should get slightly
different semantics through a new name, if at all.
I don't believe they are used enough to even warrant a macro, the same
way the users of svn_error_t's that want to possibly clear the error
don't use SVN_ERR.
>
> With regards
> Kamesh Jayachandran
>
>
>
> -----Original Message-----
> From: Daniel Berlin [mailto:dberlin@dberlin.org]
> Sent: Wed 06/09/2006 19:30
> To: Kamesh Jayachandran
> Cc: SVN Dev
> Subject: Re: [PATCH][merge-tracking] generalized SQLITE_ERR macro
>
> On 9/6/06, Kamesh Jayachandran <kamesh@collab.net> wrote:
> > Hi All,
> >
> > Find the attached patch and log.
> > This patch makes SQLITE_ERR to check for any expected value instead of
> > only 'SQLITE_OK'.
> >
>
> Uh, why?
>
> There is only one interesting sqlite function that will return
> something other than SQLITE_OK during it's normal behavior.
> Note that basically *every* single instance you've added below uses
> SQLITE_OK except for the statement stepping.
> If you really want to do this, make a new macro that takes the value,
> and use it in the one or two places that need something other than
> SQLITE_OK.
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 6 19:08:32 2006