Re: [RFC] Exceptions in the engine

On Sat, Oct 26, 2013 at 3:14 PM, Rowan Collins <rowan.collins@gmail.com>wrote: > 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. +1 for the last ideas. I'm not +1 for having such a change in the 5.x branch. However, I'm full +1 to have this change + others (Warnings, Notices, etc... to exceptions), having refactored all the code ; for a 6.x branch or whatever major number it'll be. Starting trying to keep some BC, but not all, to make people half happy, but not too much nor less , is just a mistake, IMO. it will add confusion and mess in PHP, and we don't really need that :-p Your ideas are great, the patch is at an advanced stage , but such ideas and changes should definetly not go for 5.x branch. About next major, we have not decided yet which next version PHP will be. We all talked about a possible 5.6 , but if we could have a massive contribution wave, with great ideas like this one , then we could break BC, and make PHP-next a major release. Julien.Pauli