Re: Error handling brainstorming

On Sat, Aug 4, 2012 at 1:16 AM, Stan Vass <sv_forums@fmethod.com> wrote: 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). are you sure about that? E_STRICT is more about code that works but relying on some quirk or side-effect or simply does a stupid thing. Well think about it. Why is it a goal to let quirky/stide-effect/stupid code run? This almost always ends badly. It also reduces compatibility between code libraries. I.e.: it is the opposite, we allowed sloppy code in the past, and introduced E_STRICT to allow the pedantic people to find and fix the quirks and E_DEPRECATED for finding and migrating the code which will go away. If you use a well tested, popular library by "sloppy" coders who don't mind E_STRICT and E_NOTICE, but you're "pedantic", what happens? You have to live with your error log filled with noise from the library or fork the library. And when the "sloppy" coders miss bugs because they've decided the real PHP is about sloppy code that still works somehow, they miss bugs and then blame themselves or PHP for being a language that allows buggy code. This is the end result if trying to turn PHP into everything for everybody. Instead, PHP should make up it's mind and stop littering the php.ini with semantics/behavior configuration for the language. Have one behavior. Stick with it. Make it obvious.