#25714 [Fbk->Opn]: static calls of PEAR::setErrorHandling within classes
| From: | kalkbrenner at jobpilot dot com | Date: | Thu, 02 Oct 2003 07:19:17 +0000 |
| Subject: | #25714 [Fbk->Opn]: static calls of PEAR::setErrorHandling within classes | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-22296@lists.php.net to get a copy of this message | ||
ID: 25714
User updated by: kalkbrenner at jobpilot dot com
Reported By: kalkbrenner at jobpilot dot com
-Status: Feedback
+Status: Open
Bug Type: PEAR related
Operating System: Linux
PHP Version: Irrelevant
New Comment:
You're right! I upgraded to 1.3b1 and everything works like it should
be. So it seems that the bug will be fixed in the next stable version.
Thanks for verifying my bug report!
Previous Comments:
------------------------------------------------------------------------
[2003-10-01 17:21:08] cellog@php.net
have you tried this with PEAR 1.3b1? I see:
first try: I'm dead!
If you still see the error, then please let me know, otherwise I will
mark it bogus.
Incidentally, all new PEAR-related bugs should be opened at
pear.php.net
------------------------------------------------------------------------
[2003-10-01 09:57:13] kalkbrenner at jobpilot dot com
Description:
------------
If you call PEAR::setErrorHandling(...) staticly to change the global
error handling temporarily within a method of a class, it won't work if
you aterwards call a method of another class which itself calls a
method of another class that extends PEAR and raises an error.
(confusing, but see example)
Exactly this happens if you want to change the error handling before
you call DB::connect($dsn) within a method of your own class, because
DB::connect intantiates p.e. DB_mysql and calls DB_mysql::connect which
raises en error if it runs into problems.
Assumption:
The check for isset($this) in PEAR::setErrorHandling doesn't face this
situation. If you call var_dump($this) in PEAR::setErrorHandling when
running my example, you'll see that it returns the Instigator. This is
a known issue about PHP.
Extending the check to see if the value of $this inherits PEAR isn't a
solution because classes like Instigator might extend PEAR as well.
Markus Kalkbrenner
Reproduce code:
---------------
<?php
require_once("PEAR.php");
class Instigator
{
function doSomething() {
PEAR::setErrorHandling(PEAR_ERROR_DIE); // won't work
Killer::doSomething();
}
}
class Killer
{
function doSomething() {
$victim = & new Victim();
$victim->doSomething();
print "He's still alive!";
}
}
class Victim extends PEAR
{
function doSomething() {
return $this->raiseError("I'm dead!", 0);
}
}
PEAR::setErrorHandling(PEAR_ERROR_RETURN);
$instigator = new Instigator();
print "<br>first try: ";
$instigator->doSomething();
PEAR::setErrorHandling(PEAR_ERROR_DIE); // works
print "<br>second try: ";
$instigator->doSomething();
?>
Expected result:
----------------
first try: He's still alive!
second try: I'm dead!
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=25714&edit=1