When I said I'd like to see E_STRICT be fatal/exceptions it wasn't a typo. My choice isn't based as much on what the current error severity is, or what the error severity is supposed to represent in general, because I've found in PHP often the error severity has no connection with the error that's being reported. So I decided this by observing the real-world errors that use a certain severity.

Many warnings and all E_STRICT errors clearly point to bugs in the code, wrong method signatures, non-existing variables and constants being used, which can easily do actual data damage if the script keeps running in undefined state (even if the engine is just fine with it).

PHP should not split the language semantic into loose, less loose and strict, there should be just one set of semantics: the PHP semantics, and when code does something that doesn't fit, it shouldn't be an ignorable warning.

I've found this speeds up the development process, keeps bug count down and protects the site/app's data in case of bugs.

Stan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to