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: php at pointpro dot nl 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: 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. Previous Comments: ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ [2017-06-07 09:05:30] mplomer at gmx dot de > "if a file is *required* and it can't be included, it doesn't make much sense to > go on." You can say the same for a ParseError ;-) I am currently designing a simple router where it is possible that a PHP file does not exist (to avoid a central configuration), and I want to throw a 404 then. I was happy to handle this with the new PHP 7 exception concept, as this was my first use case for it ... but then I also noticed, it just does not work for non-existent files :-( IMHO it is really inconsistent to throw errors for parse-errors but then generate fatal errors for non-existent files. ------------------------------------------------------------------------ [2017-04-04 07:13:13] requinix@php.net Related To: Bug #74366 ------------------------------------------------------------------------ [2016-06-17 07:57:54] lisachenko dot it at gmail dot com I think, that we should replace all possible places with Fatal Errors with correct throwing of Error. This will give us more control over the file loading process and make it more atomic, because additional checks if(file_exists($file) && is_readable($file)) generate extra stat commands and slow. Moreover, for highload project, we can hit a situation where if succeeded, but require will fail because file was deleted after check. Code like this: try { require $fileName; } catch (Error $e) { echo "Oops, " . $e; } is much more reliable than this one: if (file_exists($fileName) && is_readable($fileName)) { @include $fileName; // Silencing errors for the case of race-condition, etc } ------------------------------------------------------------------------ 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