[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH][merge-tracking] generalized SQLITE_ERR macro

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2006-09-06 19:07:13 CEST

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

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.