apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: APR Error Handling
Date Mon, 09 Jul 2001 21:16:27 GMT
On 9 Jul 2001, Ian Holsman wrote:

> 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.

You don't have to.  If I have a library that calls another library then I
would be responsible for making sure the two's error codes don't clash.

> 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.

The problem I see, is what happens when two different libraries call

apr_register_error_range(0, 25, handle_error);

Basically, how would this function handle two libraries conflicting.

I would much rather just follow the errno convention, that APR handles
it's own error codes, and allows other libraries to return their own error
codes.  Having APR try to manage every packages error codes is not
feasable IMHO.

Ryan


_____________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net
-----------------------------------------------------------------------------


Mime
View raw message