Exceptions and Errors

There is 1 problem with this approach. Currently an uncaught
exceptions
results in a fatal error (E_ERROR) meaning that if a particular
method throws
an exceptions it MUST be caught otherwise the script will terminate.
Having
to wrap some methods inside exceptions can be extremely frustrating
since you
may want to allow those methods to fail.

Yes. This sucks. Maybe PHP should only issue exceptions for problems
of E_WARNING severity. An exception is an "Exceptional Event." If you
have an E_NOTICE or E_STRICT then that's an informational event, not a
exceptional one.

I'm fine with this, but it's really just a documentation problem,
right? Your method can still fail, you just need to try/catch around
it.

try {
$obj->bornToFail();
}
catch(Exception $e){}

Uglier than just swallowing a warning for sure, but still just a doc
problem.
Might there be a possibility that an exception inside a "@ context" could
be ignored, too (that might also work with active custom error handlers,
I guess)?

Cheers,
Michael

Still, you shouldn't be ignoring E_WARNINGs unless you have a good
reason.

There are plenty of situations where E_WARNING can be safely ignored. And even
more situations where E_NOTICE/E_STRICT can be ignored.

Well, like I said, I'm against exceptions on E_NOTICE/E_STRICT. I
think there's some agreement on this point. Well, you, me, George, and
Derick. I add Derick because he's always against exceptions. :)

As to E_WARNINGs, what to do? Sometimes they can be safely ignored,
but it takes an experienced programmer to know those cases.

Your code cannot correctly retrieve those rows from the
database when you've ignored the error telling you that there was a
problem connecting to the database. :)

You may not want to retrieve the rows in the 1st place.

So you're saying you write code like:

// Don't care if this prints anything:
$db = new SQLiteDatabase('foo.db');
$r = $db->query($sql);
foreach ($r as $row) {
processRow($row);
}

I think only two sets of programmers do this. Unfortunately, they're
at the spectrums. Newbies and gurus. Newbies because they don't know
any better and gurus because they know exactly what's going to happen.

I'm trying to get newbies to move into the middle range and I'm
ignoring the top 1% of developers. :)

Handling UNIQUEness queries is exactly the type of problem you're
going to need to trap. For example:

Your example is not entirely correct. You'd first need to use
$db->lastError() to the error code, $e->getCode() will return something else
all together. However the bottom line is that now your exception handling
mechanism is far more complex then it should/could be. If your block has a
query() method with a query that can fail you'd need to add special
conditions to handle it in the end you end up with an overly complex handling
mechanism.

Right. Sorry about that. I had played around with trying to get SQLite to
throw exceptions and had placed the lastError() as the exception code.

If you start putting an try {} catch {} block around every individual query
method as an alternative, then you kill the whole point of exceptions, no?

FWIW, I just checked, and Java handles this dilemma in JDBC by not
throwing exceptions upon SQL warnings. They still throw SQLExceptions
for major DB errors.

I am willing to concede that SQL parse errors aren't the best example
here, but that doesn't mean extensions should never throw exceptions.

-adam

--
adam@trachtenberg.com
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!

not end your current control flow branch. Changing E_WARNING's to
errors catchable by try{}catch{} will not only break BC, but will not
make sense for a large number of warnings currently thrown for PHP and
lead to the same inconsistencies.

There is no BC break here. We are talking about specifically new
extensions written against ZE2 which have error conditions that should
be recoverable -- and only in the object context. Since most of PHP
does not provide a object context, there is no expectation that they
should be modified for exceptions.

John has gone ahead and committed a perfect example of where exceptions
just mess things up. In the tidy extension if you try and set an
unknown configuration option it throws an exception. This is not by
any stretch of the imagination an unrecoverable error, but rather a
simple failure. Yet, if you use tidy in a script, and it is not within
a try {} catch {} block your script execution will be terminated
because the configuration option could not be resolved. This is much
less than desirable and probably confusing for someone who doesn't
understand what an exception or why he should care.

You have pulled one edge case out of an entire API, and the problem here
is probably that you shouldn't complain about setting an invalid
configuration option at all -- perhaps as a E_NOTICE. Furthermore, this
exception will only occur if you use $a = new tidy() instead of $a =
tidy_parse_file().

You might argue that python or java would throw an exception in this
case. For the majority of the java standard library and python code i
have found this the opposite, however, even conceding that, PHP should
never do this. We have the concept of warnings, in our world an error
of this type does not terminate script execution. There are even
less severe usages of warnings throughout the PHP source code, and
there is no reason to convert them to exceptions. And if you don't,
you still have the same inconsistencies.

Again, we are talking about a very specific situation (PHP 5 extensions
written using a dual-syntax model).Things in the PHP 4 branch are not an
issue here, there is no expectation that such things would be changed.

a) throw specific exceptions, not just a "tidy_exception." PHP would
need to add a library of built-in exceptions to make this even remotely
useful. this is not feasible to do at RC1.66666667

Agreed. You can't do this in the time allowed. However, you can make
things throw tidy_exception and then in PHP 5.1 throw
tidySomeOtherMoreSpecificException which extends tidy_exception.

b) don't throw exceptions except when truly exceptional. a function
failing is usually not an exception, but rather signified by failure.
The exception to this is when using constructors that contain logic
(considered bad practice by many btw), and overloading. In these cases
exceptions are used in leu of a better solution. This brings us back
to KeyError - KeyError is only thrown when overloading is used:

If you're argument is that there should be some sort of consistency on
when an error is really an exception, I can't agree more.. However, that
it itself is an admission that there is a place for Exceptions in
internal PHP 5 OO which is not being addressed.

Most of the exceptions i've found when using both these languages
happen on something that maps to something more severe than a
configuration option not being found. YMMV.

Its a two-line change that I'm willing to make -- I'm more concerned
about the other extensions which are not using exceptions at all,
especially when they are warranted.

John

--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handbook http://www.php-handbook.com/
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=

I like OO (*), and I think warnings (non-fatal errors) as exceptions
are a stupid idea. Does that count? ;-)

Exceptions in languages like Java are used explicitly to catch fatal
errors, not to catch basic errors.

If 'languages like Java' means languages designed for OO, then this
is not true. Python throws exceptions for almost everything
(KeyError, for example). Even Java throws exceptions
(java.sql.Exception) for things like failed database connections
which are warnings in PHP.

Languages like Java doesn't mean languages designed for OO, but
languages closely adhering to the OO model that PHP uses, Java being
the language that can most easily be called the parent of our current
model - although I do keep Python in this context even after your
KeyError example. The triviality of an exception doesn't make
exceptions themselves less severe. Whether or not a KeyError is
warranted as an E_ERROR, doesn't in fact change that a KeyError will
bump you firmly out of your control flow branch, and make you handle
an error condition. In PHP, E_WARNINGs may be misused (that's a
discussion for another time, i think); but the fact remains, they do
not end your current control flow branch. Changing E_WARNING's to
errors catchable by try{}catch{} will not only break BC, but will not
make sense for a large number of warnings currently thrown for PHP and
lead to the same inconsistencies.

A KeyError is an E_NOTICE in PHP. It's so frequent in loosely typed
languages that it is rarely severe. Your argument is a tautology: the
only reason it breaks control-flow in Python is because it's defined
to break control-flow there by means of it being an exception.

John has gone ahead and committed a perfect example of where
exceptions just mess things up. In the tidy extension if you try and
set an unknown configuration option it throws an exception. This is
not by any stretch of the imagination an unrecoverable error, but
rather a simple failure. Yet, if you use tidy in a script, and it is
not within a try {} catch {} block your script execution will be
terminated because the configuration option could not be resolved.
This is much less than desirable and probably confusing for someone
who doesn't understand what an exception or why he should care.

I don't have a strong feeling about this either way, but to play devils
advocate: You requested an option be set. That option could not be set
because it is impossible to set a non-existent option. How do you know
how someone wants to handle that error?

You might argue that python or java would throw an exception in this
case. For the majority of the java standard library and python code i
have found this the opposite, however, even conceding that, PHP should
never do this. We have the concept of warnings, in our world an error
of this type does not terminate script execution. There are even
less severe usages of warnings throughout the PHP source code, and
there is no reason to convert them to exceptions. And if you don't,
you still have the same inconsistencies.

The discussion was on OO code throwing exceptions. Given that there is
very little OO core code in php4, I don't see a widespread conversion
happening.

Java and Python both use a mix of philosophies, and indeed there is no
complete consensus. However, in my experience and the books that I've
read on the subject, the general thought is:

a) throw specific exceptions, not just a "tidy_exception." PHP would
need to add a library of built-in exceptions to make this even
remotely useful. this is not feasible to do at RC1.66666667

But the beauty of OO Code is that all the tidy exceptions should derive
from TidyException. So life can continue as before, with no BC break.

b) don't throw exceptions except when truly exceptional. a function
failing is usually not an exception, but rather signified by failure.
The exception to this is when using constructors that contain logic
(considered bad practice by many btw), and overloading. In these
cases exceptions are used in leu of a better solution. This brings us
back to KeyError - KeyError is only thrown when overloading is used:

names = ["barney", "fred", "wilma"]
print names["betty"] # throws an exception
print names.get("betty") # returns None

You'll have a hard time defending Python as being restrained in it's
use of exceptions for warnings. It's a rather exception-happy langugae
and throws exceptions for the equivalent of most PHP E_NOTICEs.

Most of the exceptions i've found when using both these languages
happen on something that maps to something more severe than a
configuration option not being found. YMMV.

The key point that you're missing in all this is that you don't know
what's a serious error and what's not. Only the developer knows. For
instance, the python smtplib can throw any number of exceptions based
on bad connect data or bad command responses. Is this a 'serious'
error? It depends. If sending a mail is an inconsequential part of
the app, maybe it's just an informational warning. It's also easy to
imagine it being a very critical, non-recoverable error. The severity
of the error lies entirely in the purview of the receiver.

Nothing sums this up for me better than KeyError, which is almost never
fatal in my applications but which constantly bites me in the ass.
Obviously your experiences may differ, which is really the whole point.

George