Re: [RFC] Exceptions in the engine

On 25/10/2013 14:02, Joe Watkins wrote:

On 10/24/2013 11:31 PM, Larry Garfield wrote:

As a PHP user-space developer I love this idea. However, I share the concern of others here that it could result in BC unpleasantness, even if limited to the E_FATAL and E_RECOVERABLE_FATAL use cases. I don't know off hand how various versions of Drupal would handle this. --Larry Garfield

How could anything be reliant on the behaviour of a fatal error in any meaningful way ??

I think there's an important distinction between "not breaking any backwards compatibility" and "breaking backwards compatibility in an acknowledged way having weighed the impact". A change is only 100% backwards compatible if an existing valid script would behave identically on the old and new versions, with the change only being visible if the programmer explicitly takes advantage of it. The short-hand array syntax fulfilled this requirement, to the best of my knowledge; the introduction of Traits didn't quite, because it reserved a few keywords, but that was its only impact. Throwing exceptions for things which were previously fatal errors will change the behaviour of existing scripts in several ways, some of which are the stated aims of the RFC: 1. Messages previously issuing E_RECOVERABLE_ERROR will no longer trigger handlers registered with set_error_handler() 2. It will no longer be possible to catch an E_RECOVERABLE_ERROR and continue in the same context 3. If all uses of E_RECOVERABLE_ERROR are converted to exceptions, that constant will become redundant, and all uses of it, e.g. in error_reporting() bitmasks, will become meaningless. 4. catch(Exception) blocks will pick up the errors, unless a BaseException is introduced 5. The handler registered with set_exception_handler() will (presumably) be called for such errors 6. If a BaseException *is* introduced, typehints of class Exception will fail for some exception objects (I spotted this noting that the documentation for set_exception_handler implies a callback with such a typehint) 7. Finally blocks and destructors will be called when an error occurs 8. As a consequence of the above, previously impossible codepaths and program states will become possible 9. It will become possible for multiple "fatal" errors to occur in a single script execution, since code will continue executing after the first is thrown as an exception I don't think there can be any doubt that this change would break *some* backwards compatibility, even if a BaseException is introduced (which seems sensible) and E_RECOVERABLE_ERRORs are left untouched (which seems unfortunate). The question then becomes if it is an *acceptable* break, due to the behaviours affected being considered marginal enough to ignore - and also whether the value of having this in 5.x outweighs the cost. Don't get me wrong, I would love to see error handling in PHP cleaned up, but I'm not convinced that doing it piecemeal in non-breaking steps is either possible or desirable. I'd like to see this expanded into a fully considered mechanism which would be a fitting backbone for a major release. -- Rowan Collins [IMSoP]