You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Ian Holsman <ia...@cnet.com> on 2001/07/09 22:07:31 UTC
APR Error Handling
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.
..Ian
--
Ian Holsman
Performance Measurement & Analysis
CNET Networks - 415 364-8608
Re: APR Error Handling
Posted by dean gaudet <de...@arctic.org>.
On 9 Jul 2001, Ian Holsman wrote:
> 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.
hee!
sorry, just thinking back to discussions several years ago.
even within a typical libc there are at least two error mechanisms --
errno/strerror(), herrno/hstrerror(). if you're using glibc then you've
also got gdbm_error/gdbm_strerror(). if you use zlib theres an error with
each file handle and gzerror() to get the string. the list goes on.
btw, an alternative to trying to define an exception mechanism for C
(which i *think* you'll end up if you continue thinking about this) is to
combine apr and apr-util into one library so they can just do their
"registering" at compile time :)
-dean
Re: APR Error Handling
Posted by rb...@covalent.net.
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
-----------------------------------------------------------------------------
Re: APR Error Handling
Posted by Ian Holsman <ia...@cnet.com>.
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
Re: APR Error Handling
Posted by rb...@covalent.net.
> > > 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.
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: APR Error Handling
Posted by Ian Holsman <ia...@cnet.com>.
On 09 Jul 2001 13:11:07 -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.
>
> Ryan
>
> _____________________________________________________________________________
> Ryan Bloom rbb@apache.org
> Covalent Technologies rbb@covalent.net
> -----------------------------------------------------------------------------
--
Ian Holsman
Performance Measurement & Analysis
CNET Networks - 415 364-8608
Re: APR Error Handling
Posted by rb...@covalent.net.
> 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.
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------