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
