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!