apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: [PATCH] letting the app do something useful when apr_proc_create() fails in the child process
Date Wed, 05 Feb 2003 20:19:51 GMT
William A. Rowe, Jr. wrote:

> At 11:53 AM 2/5/2003, Jeff Trawick wrote:
>
> >on APR not providing a string which tells what type of processing failed:
> >
> >With no string from APR, you don't know if, for example, the failure 
> was EPERM because
> >
> >a) permissions on working directory were bad
> >b) permissions on executable were bad
> >c) no permission to raise rlimits to specified value
> >
> >A certain large class of users would really benefit from such 
> information, even if it is not in their native language and they have 
> to feed it into google.  (But surely if we'd eventually translate 
> other APR strings then an infrastructure would be in place.)
>
>
> Oh, I agree there.  I just wouldn't stuff the program name and do
> the string munging, let the user format it all.  What about simply
> passing a status flag so the callback can actually react to those
> different cases (e.g. APR_PROC_FAIL_CWD, APR_PROC_FAIL_LOAD,
> APR_PROC_FAIL_PERMS etc)?

I did consider different enums to cover different processing steps that 
might fail but I'd then want APR to give me a stringify function so I 
didn't have to check the enums myself and potentially have to make my 
program smarter when APR added a new potential failure point.  Too 
complicating.

>
> Of course, also pass the actual apr_status_t from the operation
> that failed.

yep, have to have that


Mime
View raw message