Re: [PATCH] Redirect on Error
| From: | Ilia A. | Date: | Mon, 25 Nov 2002 19:22:46 +0000 |
| Subject: | Re: [PATCH] Redirect on Error | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-91539@lists.php.net to get a copy of this message | ||
On November 25, 2002 01:58 pm, John Coggeshall wrote:
> >Multi-lingual error codes open's up pandora's box, let's not go
> >there.
>
> I have to disagree with you here Sterling. Worrying about support for
> non-english errors in php-general, etc is a bad, bad excuse not to
> implement them. The benefits of a completely constant-based error system
> (with human-friendly errors just because we like them) is worth
> consideration and I really feel is a positive addition to PHP. The only
> pandora's box your worried about (at least from the sound of your
> e-mail) was your inbox size ;) Or am I missing something?
>
> >In conclusion to both (imho)::
> >English is fine. Uncatcheable parse errors is also fine.
I for one completely agree with Sterling. Localization of errors in wrong
because it creates an inconsistent behavior, each user will see a different
error depending on the locale they are using. This will not only make things
confusing but make resolving bugs & errors so much more difficult for both
PHP developers as well as users themselves. Consider that a hosting provider
in France decides to compile their PHP with error messages localized in
French. Suddenly all their non-French speaking clients of that provider
cannot understand what the PHP error messages say. Not only that. but what
will happen with distributable PHP applications when a user reports an error
to the developer(s) and that error is localized. 9 out of 10 times the
developer will ignore the report because he has no clue what the error means.
Most common fatal error is a parse error, it is the result of carelessness. In
a production enviroment there is no reason why it should happen. I see no
reason to add complex redirection code which only obfuscated the cause of the
problem. Most people don't associate error 500 with a PHP process, this is
usually something reserved to CGI, meaning that people will look for the
cause of the problem in the completely wrong place.
As for adding XML and other nastiness, why?!?! Error reporting should be dead
simple and not involve compile time or realtime parsing and so on. Ideally
the error reporting mechanism would set an error code inside $php_errno and
then a user can either handle the error themselves in a appropriate manner or
use something akin to php_errno(); to display the text explanation for the
error itself (this is a bastardized version of the error reporting mechanism
proposed by Stig Bakken).
Ilia