I have used Exceptions and I do agree that they make some things
easier. But it makes it harder (IMHO) to deal with program errors
in-code. Such as if you fail to connect to one server (say, FTP) you
may want to try another before telling the user. In this way, it gies
from an Error (Exception) in the code called to a warning in the code
that is calling. This forces the app to use Exceptions for a kind of
code flow, which is usually said to be bad. See my e-mail from earlier
on for more.
Alexy made a very smart comment early on in the discussion, it basically revolved around the point that if an error can be ignored, it will be (error returns are very easy to ignore). If ignoring that value, then leads to an unstable/unpredictable situation, debugging becomes all the more difficult:
eg.
$x = DB_DataObject::factory('mytable');
$x->find();
while($x->fetch()) {
. ...
}
If mytable doesnt exist: the resulting errors are.
In PHP4,(with error returns) find() is not a method of PEAR Error..
In PHP5 (with exceptions) Unhandled Exception "DB_DataObject::Factory() : Could not Create DataObject from mytable, on line......"
The recomendations I've seen (based around trying to avoid exceptions for code flow) have suggested using:
if (true !== $x = DB_DataObject::canLoad('mytable')) {
.echo $x->toString();
}
I'm sure there are situations where that is more suitable than throwing an exception.. but thats probably up to the developer to decide.
What still concerns me is that there is no lightweight Warning mechanism (read as short as PEAR_Exception is currently) that will provide 99% of everyones needs, yet still have delegates/Observers that could implement ErrorStack.
Regards
Alan