Re: [PATCH] Redirect on Error

From: Date: Tue, 26 Nov 2002 11:53:59 +0000
Subject: Re: [PATCH] Redirect on Error
References: 1 2 3  Groups: php.dev 
Request: Send a blank email to php-dev+get-91734@lists.php.net to get a copy of this message
At 12:46 26.11.2002, Maxim Maletsky wrote:
Zeev Suraski <zeev@zend.com> 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.
3. 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.
I could have done without but wanted to add more flexibility (show important function 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 maxim@php.net
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

« previous php.dev (#91734) next »