Re: Exception misinformation

Justin Patrin wrote:

$loaded = false; while(!$loaded) { try { $strategy = array_shift($loadingStrategies); $strategy->load($file); $loaded = true; } catch (Exception $e) {} }

Yes, I thought of this as well. Yours would loop forever if none that worked, though. Maybe something like this: $loaded = false; $strategy = true; $exceptionMessages = ''; while(!$loaded && $loadingStrategies) { try {

    $strategy = array_shift($loadingStrategies);
    $strategy->load($file);
    $loaded = true;

} catch (LoadingException $e) {

    $exceptionMessages .= $e.getMessage();

} } if(!$loaded) { throw new LoadingException('No loading strategies worked. '.$exceptionMessages); }

Very nice, yes. -- What's wrong with looping forever? Gotta keep PHP in shape :) But yeah, your method would throw a nice informative exception in the end. It might be cool to create a CompositeException class that was designed to hold many exception objects and return all messages with getMessage() call, __toString(), etc. That'll be a useful PEAR_Exception subclass, I think, even though that scenario probably doesn't arise all that often.

Or PEAR_Exception could be altered to allow an array of exceptions as well. Either would work. Having an explicit CompositeException would keep some extra code out of PEAR_Exception, but it would also mean more code (files) to include if you needed the funcitonality. (BTW, I did want to have a composite, I just saw that PEAR_Exception didn't allow it, so I kludged that error message).

Heh :) Yes, in this case I would argue for a subclass because the last thing we want is a bloated base class. Even if the additional functionality isn't really causing any performance penalty, people see a big linecount in PEAR_Exception and think "bloat!". I think it would be pretty uncommon to need to collect exceptions like that, so I think a subclass would be ok. Or just make your package subclass (or LoadingException in your case) implement a composite pattern. It's really too bad that all the Exception methods are final (save for __toString()). Makes a good composite pattern a challenge to say the least :) Hopefully popular demand will allow those to be overridden in PHP 5.1. At least currently you can still manually set the protected properties. I've been doing that for nested exceptions, although PEAR_Exception's handling (or rather, display) of nesting is far more elegant. Hans