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 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
