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
