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
