Generally, that has already been done for PHP 7.0.0 where
reasonable and possible, see
<https://wiki.php.net/rfc/engine_exceptions_for_php7>.

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. If on the other
hand the file is not really required, just `include` it.

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
}

> "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.

the point is with PHP7 should *anything* which is not catchable considered and handeled as bug

> 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

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.

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.

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

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?
}

Retargeting this FR for only the issue mentioned in OP, namely that require throws a fatal error. Please report separate issues for other fatal errors (after checking that there are no existing ones). Otherwise this is not actionable.

I've opened https://github.com/php/php-src/pull/5641 to address require in particular.