Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: domain of apr-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
Mail-Followup-To: dev@apr.apache.org
To: dev@apr.apache.org
From: Joe Schaefer <joe+gmane@sunstarsys.com>
Subject: apr_status_t for apr apps
Date: Wed, 29 Dec 2004 12:04:21 -0500
Lines: 21
Message-ID: <87oegd6noq.fsf@gemini.sunstarsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Mail-Copies-To: never
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
Cancel-Lock: sha1:R+rySi3T+TmypU9ngXBKUrlfXW8=
Sender: news <news@sea.gmane.org>


There are quite a few places within apreq
where some error condition is detected, and
it's of the form "some apr function call failed, 
or else something's wrong with the input data".
The first case can be handled well enough
with an apr_status_t field, but in apreq 
we don't do a good enough job with the second: 
we just log the specific error and return
APR_EGENERAL. I'd really like to replace the 
APR_EGENERAL error code with something more
specific for the few (but relatively frequent) 
cases that trigger it.

Is there some region of the apr_status_t number
range for application-specific error codes?
How do folks here normally deal with this?

Thanks!
-- 
Joe Schaefer