Guys,
I have been following the thread about error reporting thing and, I
think, it is all going off route.
Of course, the ideas John and Marcus working on both are very nice, they seem
to make many interested. But PHP's error reporting itself is very
limited. So, as often mentioned in past, the whole error reporting
logic should be redesigned at some point. PHP5 comes in mind.
I will start laying out some my thoughts to hopefully get a discussion
towards working on the complete error reporting logic. I had an
extensive experience implementing custom errors, so approve or
disapprove my ideas.
1. Error message should be ported to multiple languages. Most of the
largest app. servers do that - Oracle, for instance has a wonderful
one - you specify NLS and all the errors appear in your language.
Can't PHP be the same?
It can if, every PHP error is completely exported from C code and
stored in an XML file. The errors would be then called by passing the error
codes as numbers.
This will allow:
a) Having one XML file per language. Thus, translations can be easily
done by dozens of people without having to hassle with core and
extensions.
b) Documentation Team can edit errors files at any time and, by using
XML definitions, add any possible kind of features to it.
Something like what Marcus has been doing with docref. We could
add other important notices, relevances etc, etc. Possibilities
would be infinite.
c) Having error codes as well is handy. This can be very helpful for
docref - you can provide a link to FAQ with code in GET and help
immensely any developer understanding and debugging the error.
Few other apps do that and, I think, it could be an enormous jump for
usability of PHP.
d) Users will be able to alter their custom error codes if needed.
This could be helpful in cases when one wants to control the
appearance of error messages.
e) Any patch (like one proposed by John, for example) or
functionality on user's end that requires to recognize or store an
error can use error code to point to the specific message. For
instance, imagine this:
<?php
...
// Assume that 225 is the code for "Undefined variable" error
// message
if(!@$var) {
// Assume we have such function that returns us last error code
if(last_error_code(225)) {
echo "Failed because \$var was undefined";
}
else {
echo "Failed because \$var is an empty string, zero, null or
false";
}
}
...
?>
Of course, I know that you could use isset() function to work out
code below - I simply used it as the simplest example of
flexibility a user can have with this methology of coding.
f) You might add your own errors by reusing the same logic.
For instance:
<?
// If you don't have error stored in XML,
// define it run-time:
register_error(346, "Hey, this is what I failed like");
// To use it do simply:
trigger_error(E_ERROR, 346);
// throws user defined error on screen
?>
Or, for instance, one can alter error message per-script in order
to have it differently for his case:
<?
modify_error(225, "Undefined Username");
// instead of just "Undefined Variable"
?>
And things like this. Very, very useful for debugging logistics.
I believe that there will be the difficulty on dynamically passing
values to errors. Sometimes adding %s in messages might not be enough
because the words order isn't same in all languages. So, we should be
passing "named" values. I have done it once in one of my projects - I
can share the code.
2. Error messages can be controlled by locales runtime on multi-language
sites.
As i mentioned - this framework can be very flexible.
These are my ideas. I have been working on error reporting features
quite a few times for several clients, but mostly in PHP, where only
methodic are useful.
I think this (or whatever else that has this result) has to be
implemented in PHP from PHP5. It shouldn't break an y existing code, it
would be firstly an internal change, but it would definitely scale PHP
a lot. I would be happy to work on this if it gets approved
Now, throw all your good and bad thoughts into me :)
--
Maxim Maletsky
[EMAIL PROTECTED]
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
