I've been cut off from my e-mail since Thursday, so I'm going to have to play catch-up a little here...
Issue #1: Maxim's Error handling suggestions I completely agree with the concept of language-specific errors. I'll be happy to implement a system on that. However before we do that I think what should be changed and why needs to be explored a little more... I am pretty much in favor for most of what Maxim is suggesting on this, however one thing that I wasn't sure is being suggested is splitting the constants into two three groups -- type, module, error. Where E_NOTICE, E_ERROR, etc. would be the type of error, MOD_CURL, MOD_FOOBAR would be the module in which the error occurred and E_CURL_BADURL would be the actual error code. As for custom error codes, I'm not sure how these would be handled in PHP... In fact, I'm not entirely convince that we really should have this sort of thing (i.e. trigger_error()). In my experience (and maybe I'm unique) I have never actually used trigger_error() in any sort of meaniful way. Rather, I simply deal with the error myself. I am open to hearing everyone's ideas on what could be done in this respect.. The best thought I would have is similar to Maxim's, where you could register your own module constant (see above) and error codes... Then PHP could just look them up in the XML document. Perhaps if this system was available (along with my patch) I'd be using them much more frequently. As for actual implementation, there would need to be a couple new directives: error_dir The directory containing the XMLs default_error_lang The language default for errors (perhaps we could use an already existing language directive?) And a few functions added/mod'd: Trigger_error($mod, $error) -- trigger an error with code $error in mod $mod (the type of error, E_ERROR, etc, is taken from the XML) Register_error($type, $mod, $error, $msg [, $lang]) -- register an error at runtime of type $type for module $mod, errorcode $error with the message $msg. An option parameter $lang specifies the language the error is in Include_errordef($file) -- Include an error defination XML file at run-time Set_error_language($lang) -- Set a new error-language (perhaps this would be better to just be set_language() for all of PHP?) Of course callback custom error handlers would have to be changed to accept only $mod, and $error Notice I left Maxim's suggestion of modify_error() out... The reason is because there should be no reason to modify the error message at runtime... If you want to specifically define an error to distinguish between an undefined username and an undefined variable.... Register_error(E_ERROR, USER_MYSCRIPT, E_MYSCRIPT_UNDEF); If(!isset($username)) trigger_error(USER_MYSCRIPT, E_MYSCRIPT_UNDEF); Issue #2: The 500 error... I'm -1 on this. The reason I'm -1 is because no one has shown me a reason why the 500 error is a more reasonable solution than the Patch I've already written which accomplishes the same thing. In fact, it does a better job because the error page knows exactly what went wrong (unlike a 500 error, which just means something went wrong). Issue #3: The redirect patch Although there are a few things to do for the patch before I commit (make it more friendly when other error handlers are used, use the argument_seperator from the INI, etc) it is basically ready and working. If no one has any serious objections I'll clean up the code and commit it when I've tested it. Also, this works out fairly well because the patch can be easily modified to work with the "new" system Maxim discussed. My 2c -- sorry for being long winded (had to catch up). John -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php