Date: Sun, 4 Dec 2011 11:41:34 -0500
From: Austin Clements <amdragon@MIT.EDU>
To: Jani Nikula <jani@nikula.org>
Subject: Re: [PATCH v2 1/2] cli: introduce the concept of user defined hooks
Message-ID: <20111204164134.GT16194@mit.edu>
References:
 <7fbe6befcf31881a9bca672f55b93501249a220c.1322859389.git.jani@nikula.org>
	<6688b09fffa2a66b496af78008102f88ab4e9450.1322953841.git.jani@nikula.org>
	<20111204034210.GA16405@mit.edu> <87sjl0ldk0.fsf@nikula.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87sjl0ldk0.fsf@nikula.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: notmuch@notmuchmail.org
Precedence: list

Quoth Jani Nikula on Dec 04 at  2:35 pm:
> > > +int
> > > +notmuch_run_hook (const char *db_path, const char *hook)
> > > +{
> > > +    char *hook_path;
> > > +    int status = 0;
> > 
> > You use status as both a notmuch_status_t and for generic C library
> > results.  This seems a little weird.  You may or may not want to do
> > anything about it.
> 
> True, it's not consistent. I'll want to do something about it. I wonder
> if it's worth returning anything other than ok/fail from this function
> anyway.
> 
> There seems to be some confusion in notmuch_status_t usage across
> notmuch cli. Should notmuch cli return a notmuch_status_t as exit
> status? It currently does at least in some cases, but it also returns
> plain 1 too which is (unintentionally) NOTMUCH_STATUS_OUT_OF_MEMORY.
> 
> Does it make sense for the cli to use the lib statuses internally
> anyway; you wouldn't want to add new status codes to the lib just to be
> able to use them in cli.

I think the answer is that there's no good answer because error
handling in C is so lame.  In this particular case, I'd say there's
little point in distinguishing different errors (and especially no
point in returning not-quite-appropriate status codes), so perhaps it
should follow the 0/1 convention.