Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: domain of mihailim@gmail.com designates
 64.233.170.199 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=bxHmxQBstK/vsI4qjQwBanpWCyfc8UhxmcL/HSkJg6rkgQOMTLcLGxUvzoGOCIV7uSYXdWtf7Agh/t/z50KfRFNLK/zK62gZa9S9i0giePQWUJm4IYF+0U0dJC6fdd2czLxQc2+pr7lel2hM5kF6wCj4MyRf7PksvVVueOztj88=
Message-ID: <e0c98d041227094051fb0fd6@mail.gmail.com>
Date: Mon, 27 Dec 2004 19:40:30 +0200
From: Mihai Limbasan <mihailim@gmail.com>
Reply-To: Mihai Limbasan <mihailim@gmail.com>
To: Garrett Rooney <rooneg@electricjellyfish.net>
Subject: Re: apr_status_t testing against APR_SUCCESS usage question
Cc: Cliff Woolley <jwoolley@virginia.edu>, dev@apr.apache.org
In-Reply-To: <41D047CA.6040600@electricjellyfish.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <e0c98d04122702401e69c6e0@mail.gmail.com>
	 <41D01FB6.2040605@electricjellyfish.net>
	 <Pine.GSO.4.58.0412271219390.15965@cobra.cs.Virginia.EDU>
	 <41D047CA.6040600@electricjellyfish.net>

Check, I hear you. I'll split it tomorrow then (tired right now and
working while tired is a no-no) and resubmit the
positive-success-report version.


On Mon, 27 Dec 2004 12:35:06 -0500, Garrett Rooney
<rooneg@electricjellyfish.net> wrote:

> Ok, I think we may be talking about two different cases...
> 
> There's the "check if a call returned an error, and if so return that to
> your caller" case, which personally I think is easist to read as:
> 
> if (rv)
>    return rv;
> 
> If there is an error, we return it, the code does exactly what you would
> read out loud if you were reading it to someone.  In Subversion land we
> make it even more explicit by using 'err' or 'apr_err' for the variable
> holding the status, instead of rv, but even without that it's still more
> readable this way IMO.
> 
> And there's the "check if a call succeeded, and if so return that to
> your caller" case, which I'm not all that picky about.  Perhaps
> including APR_SUCCESS there in some manner is probably best, as it makes
> it clear that we're looking for success.
> 
> The patch seems to deal with both situations, and in the first case I
> just don't see how it helps other than making things more verbose when
> there's little need.
> 
> -garrett
> 

-- 
Mihai Limbasan