Re: [PATCH] letting the app do something useful when apr_proc_create() fails in the child process

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 02:19 PM 2/5/2003, Jeff Trawick wrote:
>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.

Can we create a flavor of apr_errorstring for this purpose, then?  Pass
the apr_errorstring_proccreate() fn the apr_procattr_t, the apr_status_t
and the reason, and get back a thorough explanation string of the failure?

Bill