httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: [PATCH multi-env] remove size() functions, empty string on n==0, apreq_fwritev() rewrite
Date Fri, 11 Mar 2005 14:38:04 GMT
Max Kellermann <max@duempel.org> writes:

> On 2005/03/11 04:03, Joe Schaefer <joe+gmane@sunstarsys.com> wrote:

[...]

>> Ugh, that's bad.  How about we replace all APR_EGENERAL error
>> codes with APREQ_ERROR_GENERAL?
>
> What's the difference between the two?
>
> Disadvantage of custom status codes is that ap_log_rerror() can't
> handle a custom libapreq status code correctly...

That's infinitely better than reusing the status codes from apr.
If it's an apreq function that is choking, the status code should
be in the APREQ_ERROR_ range.  We'll have to deal with ap_log_rerror 
not understanding those errors anyway, so by adjusting all the
APR_EGENERAL uses to APREQ_ERROR_GENERAL, the required wrapper code 
for ap_log_rerror will automically DTRT.

> or when some other function is just passing a status code from
> libapreq to its caller, which then handles it as "normal" APR status
> code.

Not our problem.  In an ideal world, all possible status codes
(or ranges of status codes) that a function may return are 
documented.  If a function wants to hide the fact that they
are using apreq, they need to translate the APREQ_ERROR
codes into something else before exposing it to the user.


> So, is APREQ_ERROR_GENERAL really needed?

Needed, no. Better than APR_EGENERAL?  I think so.

-- 
Joe Schaefer


Mime
View raw message