At 12:46 26.11.2002, Maxim Maletsky wrote:
Zeev Suraski <[EMAIL PROTECTED]> wrote... :
> At 13:11 26/11/2002, Maxim Maletsky wrote:
> >That sounds selfish of us, Derick.
>
> No, it doesn't. If we're going to attempt at doing something that has a
> high risk of screwing up PHP and slow down its QA and support, we should be
> mature enough to know our limits. If we don't, the ones that would suffer
> eventually would actually be the users.
>
> Knowing your limits is a virtue, and taking unnecessary risks, while may
> seem noble, will often lead to much worse results.
Let's say, as a user, I get this error for not defining a variable:
Notice: Undefined variable: var in E:\CVS\PHP\php4\Release_TS\tests\release.php on line 20
What if that error would be:
Notice (235): Undefined variable: var in
E:\CVS\PHP\php4\Release_TS\tests\release.php on line 20
Docref...
FAQ...
etc ...
where
1. "Underfined Variable" is translated to ohter languages. In this
example it is just a "simple english", but there are other, more complex
ones.
2. 235 is the error code. One can type it in google: "Notice (235)" and
get lots of info. Still possible even now, by typing error message
instead. What i love about Oracle is its error code format: "ORA-25688"
- you type it anywhere and get find tons of solutions instantly.
Then why strip the module from the error code. I like that hint in the oracle messages much.
I could have done without but wanted to add more flexibility (show important function3. Docref and FAQ links to a documentaion and FAQ pages on php.net where there would be descriptions of errors and relevant solutions. Very, very handy. It is what Marcus was doing, but, he needed to add new functions to it, referencing by code will be more flexible as you could edit the storage only.
parameters and allo to use another link) and pass around TSRM parameter for speed
reasons.
4. User could use and extend this error reporting techniques on his own. These are just my thoughts of what I would see usable about it all. IMO, the current error reporting will be someday dedesigned anyway - it does need a redesign. -- Maxim Maletsky [EMAIL PROTECTED]
There were some good points to consider in these threads but i disagree that we need a complete redesign. As myself and even more Sascha showed i18n messages can easiliy be added to the current system. When it is up to add error code more work is needed without a question. The thing i fear most about further changes is that we either need new API functions to handle the error codes or we end up in endlessly bugs about php not compileable because some errors need to be changed. That is one of the reason i left the change from php_error() to new php_error_docref() to the authors of the modules and gave them a nice tool to aid them. marcus -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
