#25714 [Opn->Csd]: static calls of PEAR::setErrorHandling within classes

From: Date: Thu, 02 Oct 2003 11:14:32 +0000
Subject: #25714 [Opn->Csd]: static calls of PEAR::setErrorHandling within classes
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-22311@lists.php.net to get a copy of this message
ID: 25714 Updated by: cox@php.net Reported By: kalkbrenner at jobpilot dot com -Status: Open +Status: Closed Bug Type: PEAR related Operating System: Linux PHP Version: Irrelevant Previous Comments: ------------------------------------------------------------------------ [2003-10-02 03:19:17] kalkbrenner at jobpilot dot com 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! ------------------------------------------------------------------------ [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

« previous php.pear.dev (#22311) next »