Same here, have been getting that behavior as well. Keeping fatal errors from users would be nice. It would also let us exit gracefully, and not leave the users hanging.

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Just register an error handler that throws an exception.

Hey, dear helly@php.net,

Does you can read?!... I have posted under "Feature/Change Request" category, not "Bug"!!!... It appears that you, not me, should read things more carefully!!!...

Actually, since this is not an E_RECOVERABLE_ERROR, but instead an 
E_ERROR, the error handler approach won't work

<?php
function err($num, $message)
{
    throw new Exception($message);
}
set_error_handler('err');
try {
    $oops->method();
} catch (Exception $e) {
    echo 'caught';
}
?>

results in a fatal error.

I'm NOT saying making that an E_RECOVERABLE is the right approach, 
as it leaves the engine in an unstable state, just that an error 
handler is impossible for this particular issue.  Probably "Won't 
fix" is more appropriate than "Bogus"

First my answer was a canned reply with an additional explanation.

Second E_ERRORS will never be handable in user mode. No matter what or how happens. So the only thing that can be done is changing particular E_ERRORs into E_RECOVERABLE_ERRORs. But only if we can make the engine stay in a recoverable state after the error in question.

Third my answer still holds. Simply provide an error handler that converts the errors to exceptions and be done.

Dear Sirs,

First of all, excuse me for the mood of the previous post.

I will try to explain in a more detailed manner the question.

In the initial post, I said: "[...] enhance the 'try, catch' Statement so that Code inside 'try' would transparently cause a Fatal Error [...]". What did I mean by this?
If the Code fragment provided there ( initial post ) were translated to C, C++, Java, VB.Net -- or VB, through the horrendous yet powerful "On Error" Statement -- or JavaScript ( perhaps, also Python ), all translations would have exactly the same output:

# [global] -- causing a Fatal Error...
# [global] -- some handling being executed...
# [global] -- [end]

This make evident that all this Languages have an "effective" Exception Handling mechanism, that is: they really allow the rise of Fatal Errors inside the "try" Block ( whose Code is said "protected" ) with no intrinsic implications for the Code that get executed latter, since this can freely check the Error condition and take any desired actions.

In PHP 5, the "try, catch" Statement was supposedly introduced to provide Exception Handling. But this "try, catch", though homologous to the existents in other Languages, have a considerably diverse role. Simply put, it "provides the programmer, for organizational purposes only, with a Structure where an Exception can explicitly be thrown ( through 'throw' KeyWord ), invoking a qualified 'catch' that follows or that is in a previous Stack level". In other words, Fatal Errors -- that is, "implicitly" thrown Exception -- still are "fatal" inside a PHP "try" Block; they still imply instantaneous Program ( Script ) abortion. Meanwhile, in the Languages with "effective" Exception Handling, an "'implicitly' thrown Exception" inside a "try" is, definitely, "non-fatal": it is just "discarded", having its Error data collected for eventual further utilization.

Summarizing, since PHP does not have "effective" Exception Handling, it, concerning the above mentioned fragment, outputs:

# [global] -- causing a Fatal Error...
# ( PHP Notice ) undefined Variable: nonObjVar
# ( PHP Fatal Error ) call to a Member Function ( "method()" ) on a non-Object

Note that did occurred Program abortion: the last message ( "[global] -- [end]" ) was not printed...

Our friend, helly@php.net, said: "Just register an error handler that throws an exception". And, after: "Simply provide an error handler that converts the errors to exceptions and be done". Unfortunately, it appears that he was not able to grasp the problem. Well, in a PHP context, the following situations, among others, constitutes Exceptions ( Fatal Errors ), not Errors:

# 1. Call to undefined Function;
# 2. Call to Methods on non-Objects;

So, this situations cannot be handled through "set_error_handler()": they rise Exceptions, not Errors. It is, though, surprising that they also can't be handled through "set_exception_handler()", because this Function is only invoked when an Exception is explicitly thrown ( 'throw' KeyWord ) -- that is, it just have an "organizational" role, just as "try, catch", having been introduced together with this in PHP 5.

Consider the following fragment:



function error($errNiv, $errMsg, $file, $errLn, $errContxt)
{
//###### this Function will never get executed
/*@@@@@@*/ echo("error() -- msg= '".$errMsg."'");
}



function exception($excObj)
{
//###### this Function will never get executed
/*@@@@@@*/ echo("exception() -- [ini]");
}



/*######*/ set_error_handler("error");
/*######*/ set_exception_handler("exception");
/*@@@@@@*/ echo("[global] -- causing a Fatal Error...");
$var0=teste(); //###### "teste()" isn't defined
/*@@@@@@*/ echo("[global] -- [end]");



The output is solely the following:

# [global] -- causing a Fatal Error...
# ( PHP Fatal Error ) Call to undefined Function "teste()"

If PHP had Exception Handling, the output should be the following:

# [global] -- causing a Fatal Error...
# exception() -- [ini]
# [global] -- [end]

Concluding: In Fact, PHP Does Not Have Any Exception Handling!!!



# Obs. 1: it would be nice if the Documentation were cleaner ( and emphatic ) about the character merely "organizational" of the "try, catch" Statement and the "set_exception_handler()" Function.
# Obs. 2: it is worth to remember that a "truly Object Oriented Language" must have "effective" Exception Handling...

helly's second reply explains everything: 
E_ERROR cannot be caught in the userspace and this is not going to be changed until the engine is not rewritten from scratch (and we don't have such plans either).
So you have to live with what you got now and it has nothing to do with try/catch - that's how the things work.
I understand that this is a change request, not a bug report, but we're not going to change this in the foreseeable future.

[ Changing Status to "Closed", since this is not simply "Bogus" ]