Req #72089 [Com]: handle all fatal errors with try catch
| From: | php at pointpro dot nl | Date: | Thu, 27 Jul 2017 20:40:25 +0000 |
| Subject: | Req #72089 [Com]: handle all fatal errors with try catch | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-210374@lists.php.net to get a copy of this message | ||
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:
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.
Previous Comments:
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
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