Aside from that none of the comments about how to deal with my Exception issue example are feasible imho.
As Justin pointed out, your example actually doesn't hold up to closer
scrutiny. I assume you'd be using the results of MDB2 to build your
graphs. And I assume your graphs are actually built using a resultset
from your database ....
$res =& $mdb2->query('SELECT m1.a,m1.b,m2.c FROM my_table1 m1, my_table2
m2 ... ');
So, how exactly does you quick prototype proceed to use $res like a
resultset when it's actually a PEAR_Error because you modified your
schema and broke things without causing a E_FATAL ("call to undefined
method...")
Now, in the Exception world, your quick prototype could be accomplished
by adding a single -- that's right, folks, 1 -- try/catch+log/ignore
block to your base GraphBuilder class. That would allow you to
aggregate a whole bunch of graphs on a page without worry that the first
one that broke would be the last one displayed.
The real argument against exceptions, it seems clear, is just an
argument about using OO design in PHP. Yes, if you didn't have a base
GraphBuilder class, then you'd have to have more try/catch blocks (at
worst case you'd need as many try/catch as you would PEAR::isError()).
While, I can admit that procedural programming has its merits & its
place in the world, I am surprised that it forms the basis for
anti-exception FUD in PEAR, which is a collection of OO components ...
I still have an overwhelming sense that the centerpiece of this "it
makes my prototyping hard!" is vaporware. But my argument would be that
even if it makes *your* applications somehow harder to develop, it
actually helps the rest of us writing OO apps immensely.
It seems to me that if there's disagreement then it should just go to a
vote. Then again, I thought this was done some time ago here:
http://pear.php.net/pepr/pepr-proposal-show.php?id=132
Hans