#40014 [Opn->Csd]: "try, catch" -- Let's Empower It, Please!!!

From: Date: Thu, 15 Mar 2007 02:53:02 +0000
Subject: #40014 [Opn->Csd]: "try, catch" -- Let's Empower It, Please!!!
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-110358@lists.php.net to get a copy of this message
 ID:          40014
 Updated by:  helly@php.net
 Reported By: marcus3v at hotmail dot com
-Status:      Open
+Status:      Closed
 Bug Type:    Feature/Change Request
 PHP Version: 6CVS-2007-01-03 (CVS)
 New Comment:

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.


Previous Comments:
------------------------------------------------------------------------

[2007-03-15 02:32:57] cellog@php.net

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"

------------------------------------------------------------------------

[2007-03-15 00:24:54] marcus3v at hotmail dot com

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

------------------------------------------------------------------------

[2007-03-13 22:28:36] helly@php.net

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.

------------------------------------------------------------------------

[2007-03-09 22:37:57] bronner dot mike at gmail dot com

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.

------------------------------------------------------------------------

[2007-01-03 20:44:54] marcus3v at hotmail dot com

Description:
------------
Hey, men!

What about to enhance the "try, catch" Statement so that the code
inside "try" would transparently cause a Fatal Error that, then, is
handled through the "catch" Blocks -- just as occurs in JavaScript?!

Reproduce code:
---------------
try {
  /*@@@@@@*/ echo("[global] -- causing a Fatal Error...");
  $nonObjVar->method(); //###### "nonObjVar" isn't defined
}
catch(Exception $error) {
  /*@@@@@@*/ echo("[global] -- some handling being executed...");
  //###### some handling...
}
/*@@@@@@*/ echo("[global] -- [end]");

Expected result:
----------------
The output would be the following:

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

Actual result:
--------------
Obviously, the output with the current implementation is the
following:

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


------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=40014&edit=1


Thread (9 messages)

« previous php.bugs (#110358) next »