Re: Error handling brainstorming

if we turn E_STRICT to behave exactly as E_ERROR there is no point keeping the E_STRICT level. personally I disagree with turning something which was a pedantic notice in one version into an unsupported feature which fatals out if you try to use it in the next. maybe E_STRICT->E_DEPRECATED->E_ERROR I do think there's no point keeping the E_STRICT level. In fact, there's no point keeping any level except - E_WARNING (strictly for developer "tips" like deprecated functionality, and not for say division by zero errors or Stream I/O errors like it is today); - E_ERROR (everything that's not a developer "tip" but an error, should be this type, not a notice/warning/strict); - E_FATAL_ERROR (direct script halt). That's just how I see it. Today we have these instead: - E_ERROR - E_WARNING - E_PARSE - E_NOTICE - E_CORE_ERROR - E_CORE_WARNING - E_COMPILE_ERROR - E_COMPILE_WARNING - E_USER_ERROR - E_USER_WARNING - E_USE_NOTICE - E_STRICT - E_RECOVERABLE_ERROR - E_DEPRECATED - E_USER_DEPRECATED Most of those have no reason to exist and especially they have no reason to be exposed as different severities at the user level. It seems like the severity levels have become a poor man's error *type* codes, which are needed, and at much more granular level, but as this is a severity, that's not the place to differentiate them. I never spoke about E_STRICT going fatal in the next version of PHP. I'm saying this in the context of my advice about using an error handler. I do this in my error handler (not just development, but also production), but still I think it could be a nice long-term goal to cleaning up PHP. Stan