Req #72089 [Com]: handle all fatal errors with try catch

Edit report at https://bugs.php.net/bug.php?id=72089&edit=1 ID: 72089 Comment by: ryan dot jentzsch at gmail dot com Reported by: paulobitfranca at gmail dot com Summary: handle all fatal errors with try catch Status: Re-Opened Type: Feature/Change Request Package: *General Issues Operating System: Linux PHP Version: 7.0.5 Block user comment: N Private report: N New Comment: As an actual case where this issue is a valid concern. Pseudocode that illustrates the issue: <?php try { SoapClient::__constructor($wsdl) } catch (\Throwable $t) { // Never executed because ANYTIME the constructor can not PARSE the WSDL a script exiting fatal is thrown and not caught! // The SOAP implementation in PHP offers ZERO fault tolerance. // We can't degrade gracefully. // All processing stops and the script is exited! // Why in the name of sanity is a SOAP PARSE issue NOT throwing a SOAPFault and instead we get a fatal error? } Previous Comments: ------------------------------------------------------------------------ [2017-07-27 21:28:48] spam2 at rhsoft dot net it's a general issue - with having Üeverything* as exception you can esily write code which handles 99.9% of all cases in a very cheap try{] while handle servers missing something in the catch part - unhandeled you get the same result as now but *you can* handle it properly ------------------------------------------------------------------------ [2017-07-27 20:40:24] php at pointpro dot nl By the way, this is issue is linked to PHP 7.0.5, but it also applies to 7.0.21, 7.1.7 and 7.2.0beta1. ------------------------------------------------------------------------ [2017-07-27 20:36:45] php at pointpro dot nl In the same train of thought, why does it make sense that running foo.php, with these contents: ---------- foo.php <?php include "bar.php"; ---------- and ---------- bar.php <?php asdfkoaw jeokjwe foijsdfklojsefwe ---------- Would throw a 'ParseError' exception that can be caught and handled, but when I replace the content of bar.php with the much more correct code: ---------- bar.php <?php class A implements B {} ---------- Gives me a unrecoverable fatal error: Interface 'B' not found. So a very big +1000 on making all failures in requiring files, and basically ALL errors, throw exceptions that can be caught. Even if the script can't continue, it can do its best to provide a meaningful or at least thoughtful error message to the client. ------------------------------------------------------------------------ [2017-06-07 09:12:16] spam2 at rhsoft dot net > With regard to your example: if a file is *required* and it can't > be included, it doesn't make much sense to go on sorry but that is nonsense - it makes *a lot* of sense to go on with a custom error-page with some useful hint instead a blank page and when it comes to modules of your application and somewhere deep there is a require() you can't do much and by the fact that is is not catchable IT BREAKS ANY EXISTING ERROR-HANDLER and you can not do anything about it while a *parse error* in some of the includes CAN be catched - typical php inconsistency for no sane reason ------------------------------------------------------------------------ [2017-06-07 09:08:46] spam2 at rhsoft dot net the point is with PHP7 should *anything* which is not catchable considered and handeled as bug ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=72089 -- Edit this bug report at https://bugs.php.net/bug.php?id=72089&edit=1