apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@cnet.com>
Subject Re: APR Error Handling
Date Mon, 09 Jul 2001 21:09:56 GMT
On 09 Jul 2001 13:56:43 -0700, rbb@covalent.net wrote:
> 
> > > > Hi.
> > > > I've got a simple library/test app which uses APR.
> > > > I would like to also use it in a apache module..
> > > >
> > > > the problem I'm seeing is that ap_log_[rp]error is in server/log.c
> > > > so I can't use that if It's not HTTP.
> > > >
> > > > I was wondering if there should be something in the APR code a APR
> > > > routine can call and which ap_log_Xerror would call to actually write
> > > > the error out.
> > >
> > > ap_log_Xerror are web server specific.  APR provides apr_strerror to
> > > provide a string interpretation of the error, but a function to write the
> > > error string to stderr is beyond the scope of APR.
> >
> > so how do we handle error loging in other libraries like apr-util??
> > all I can see is that they pass APR_EGENERAL back to the caller.
> > which If the app doesnt seg fault is probably next to useless in trying
> > to track down the error
> >
> > maybe there needs to be a method of registering error numbers/functions
> > so that apr_sterror knows that error 1230981 is from apr-util and would
> > call apr-util's function it registered to show the error message.
> 
> We already have a set of error numbers that are specific to an
> application.  As for APR-util, APR-util should be returning their own
> error codes.  If an APR-util function returns an error, then apr-util
> should have a mechanism for determining what the error was.  That may mean
> with a separate function, or by hooking into apr_strerror.
> 
> The only problem with extending apr_strerror, is that we have only
> allocated 500 error messages.  If a lot of libraries are created to extend
> the error functions, then we will run out.
> 
> I would rather see APR-util provide it's own function, and have that
> function fall back to using apr_strerror, if the error is an APR error.
> 
> That way, two libraries, apr-util and apr-iconv, could use the same
> APR_OS_START_USERERR + x value and the app would consider them two
> different errors.
> 

that won't work, as one library can always call another 
and you would lose that functionality.

what I am proposing is adding a new function to apr
apr_register_error_range( from, to, callback_fn)

which the external library would call at it's startup.
then if there is an error, apr_strerr would just call the callback.

> Ryan
> 
> _____________________________________________________________________________
> Ryan Bloom                        	rbb@apache.org
> Covalent Technologies			rbb@covalent.net
> -----------------------------------------------------------------------------
--
Ian Holsman
Performance Measurement & Analysis
CNET Networks    -    415 364-8608


Mime
View raw message