Hi all.
We need consistent error levels and handling for all modules. I suppose
all of us can agree with this.
[PROBLEM]
1) Use of error levels are not consistent. Some function returns error
status, yet displays/raises warning message for non faital errors. Other
function just returns error status. PHP is missing rather standard error
levels like E_DEBUG and E_INFO. (I understand histrical reason of this
behavior)
2) Current CODING_STANDARDS does not define use of error level.
From CODING_STANDARDS
[5] Use php_error() to report any errors/warnings during code execution.
Use descriptive error messages, and try to avoid using identical
error strings for different stages of an error. For example,
if in order to obtain a URL you have to parse the URL, connect,
and retreive the text, assuming something can go wrong at each
of these stages, don't report an error Unable to get URL
on all of them, but instead, write something like Unable
to parse URL, Unable to connect to URL server and Unable
to fetch URL text, respectively.
3) No standard for error message format.
[PROPOSAL]
1) Add new error levels E_DEBUG and E_INFO.
2) Define standard for error level usage.
E_ERROR: Fatal error that cannot continue execution.
E_WARNING: Non-fatal error that can continue execution.
This error level must be used only when there is *obvious* bug
in script. Error with this level should not be ignored for production
script. Examples are wrong number of parameters and invalid
data type for function parameter.
E_NOTICE: Non-fatal error like E_WARNING. The error would likely be a
bug in script or problem during execution. This error level may not be
ignored for production script. Examples are connection failure to
database and invalid resource passed to function.
E_DEBUG: Non-fatal error that is most likely not a bug in script, but
useful to debugging script. Errors that may be ingored safely for
production script should use E_DEBUG. Examples are stat failure for file
system funciton and use of undefined variables.
E_INFO: Informational error that is not a error or bug at all. This
error level would be useful to notify use of obsolete API, etc.
3) Error message format.
- Wrong number of paramters or wrong type
Use the same format as zend_parse_parameter() (or use
zend_parse_parameter() actually :)
- If error is not associated with module function, use module name
in error message. (i.e. MINIT, MSHUTDOWN, RINIT, RSHUTDOWN)
- For other errors, function name should be in error message using
get_active_function_name(TSRMLS_C). Programmers can assume there
is a function name in a error message, if error is raised inside a
module function.
php_error(E_WARNING, %s expects size 0,
get_active_function_name(TSRMLS_C));
[TODO]
New error levels, E_DEBUG, E_INFO, E_USER_DEBUG and E_USER_INFO are
needed. Someone must check all php_error() to confirm error level usage
standard.
[ISSUES]
Following issues need to be discussed (there may be others)
- Scripts depends on error levels/messages will have problems with
changes. Major version up is required, perhaps?
- There may be cases that are difficult to choose proper error level,
especially E_NOTICE and E_DEBUG.
- I'm not following ZE2 development closely. ZE2 might have much
better approch, is it?
- TODO-5.0 for PHP 5.0 to cleanup legacy behaviors?
- It is posssible to use #if PHP5 or #if NEW_ERROR_MSG to
keep old error level and message. Question is should we do
that or not.
- --with-all-info-msg configure option for enable E_INFO message
that shows API change info messages, etc.
Code as follows slows down PHP.
if (!strcmp(get_active_function_name(TSRMLS_C),old_function_name)) {
php_error(E_INFO,%s is obsolete function name.,
get_active_function_name(TSRMLS_C));
}
- I suppose people has better idea than me for error message format :)
If this proposal and/or new error levels are accepted, I'll volunteer to
write patch for new error levels. There are about 2300
php_error/zend_error, real hard work is fixing them, though.
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
