Hi, We started a discussion about the current error handling mechanism and the possible improvements in the "Why do disabled functions / classes generate a WARNING" thread[1], but that is a little bit offtopic there, so I decided to create a separate thread for it. Basically Etienne mentioned that the original issue was a good example why would we reconsider throwing exceptions from the core, which is currently discouraged.[2] Stan replied with the idea of turning the current error handling mechanism in php into using Exceptions for everything, but keeping some error types as is/uncatchable. [3] This was brought up on the lists multiple times, we even have two separate RFC with similar idea.[4][5] I tried to explain why I think is impossible to achieve the same functionality by turning the php errors into exceptions without a major overhaul in the engine[6][7], but it seems that I failed to do so.
First of all, I would like to clear up the few misunderstandings: Stan: You mentioned that E_STRICT (and E_ERROR but I see no problem with that) should be instant fatal error, I think that was only a typo on your part, could you please clear that up? I would also ask you to confirm that you would like to see every error levels[8] turned into exceptions except the non-recoverable ones. It seems that you and Andrew disagree on that. Andrew: >From your mails, it seems that you don't agree with Stan on turning everything but fatals into exceptions[9]. I'm really confused about that, as if we take away warnings (and by that logic everything else which is less serious than a warning) the we would only have the fatal errors (which we already discussed to not turn into exceptions and you also seemed to agree[10]), E_USER and E_RECOVERABLE_ERROR. Is this what you propose? My opinion (and this is what I tried to explain to you) is that it is pretty common in the core and the bundled extensions to raise notices and warnings left and right, and still do something, If we would turn anything less serious than E_RECOVERABLE_ERROR (so any notice, deprecation notice, strict notice or warning)into an exception, that would be a huuuuuuge BC break. Basically silecing errors through setting error_reporting level, custom error handlers or the @ operator would stop working, and one should put everything into a try-catch block to not have his code blown into his code constantly. Another thing that I mentioned: even if you catch everything, there would be some things that you couldn't do anymore. Any method which throws notices or strict/deprecated notices or warnings would be broken, as the execution would be halted (as the execution jumps into the catch) which would be a major PITA to the userland developers, and without further work, it could make the userland/engine in a more fragile state, as the original call was interrupted but the execution still continues from a different spot. With the current error handling the execution either resumes after the error handler is called, or the execution is terminates gracefully The current error handling provides a way to trigger multiple errors/warnings for an operation, and allows to still return and continue the execution. Turning everything into exceptions would kill both of those, and without providing something similar suite, we can't do that imo. So basically these are our boundaries: - Fatal errors can't be turned into Exceptions, but it was mentioned multiple times, that there are some fatals, which could be turned into E_RECOVERABLE_ERROR. - Most/all non-fatal errors could be safe to be turned into Exceptions as without explicit measures(try-catch) on the caller's side, it would still stop the execution. - Every other warning/notice/etc. which are just holds additional information but not indicating unsuccessful execution in itself cannot be turned into Exceptions. I have a few ideas about how to proceed from here, but I need some time to gather my thoughts. 1. http://www.mail-archive.com/internals@lists.php.net/msg60043.html 2. http://www.mail-archive.com/internals@lists.php.net/msg60054.html 3. http://www.mail-archive.com/internals@lists.php.net/msg60056.html 4. https://wiki.php.net/rfc/errors_as_exceptions 5. https://wiki.php.net/rfc/enhanced_error_handling 6. http://www.mail-archive.com/internals@lists.php.net/msg60060.html 7. http://www.mail-archive.com/internals@lists.php.net/msg60063.html 8. http://www.php.net/manual/en/errorfunc.constants.php 9. http://www.mail-archive.com/internals@lists.php.net/msg60061.html 10. http://www.mail-archive.com/internals@lists.php.net/msg60065.html -- Ferenc Kovács @Tyr43l - http://tyrael.hu
