Re: Exception misinformation

Bertrand Mansion wrote:

Lukas Smith wrote:

David Costa wrote:

Whilst I do appreciate the concern of few developers, I also think that there is not enough clarity on this topic. This is already part of PHP 5, like it or not e.g. Sqlite has an in-build OO interface (not document yet ...:D) e.g. new SQLiteDatabase equals to the procedural function sqlite_open $obj->queryExec(...) is like the procedural function sqlite_exec etc. Well if you do something like $db = new SqliteDatabase ('blah.sqlite'); and the db doesn't exist ...and you don't try and catch you will end up with an uncaught exception that will raise a fatal error.

Interesting you should mention that. For those who read my previous mails they should know that I very much agree that this should throw an exception. However since you are using sqlite as an example. Last time I checked it followed exactly my line of thought. Does it throw an execption if you hav ea malformed query?

Why not ? This looks like a bad example. The fact that constructors in PHP5 throw an exception is a convention and was said to be "the only sane way to handle errors that prevent object construction" recently by Wez. Then, whether a malformed query throws an exception is up to the developer. Sqlite (the library) doesn't. So to be consistent, the PHP5 extension doesn't neither. And that's good because the less exceptions are thrown by the engine, the better. So nothing prevents the user to test if the result of sqlite_query is false and then throw an exception. I think it can be handy especially because there are many reasons why sqlite_query would not complete:

[snip]

Those are the results of the sqlite_exec() and sqlite_step() C functions used by the sqlite_query() PHP function. As you can notice, a lot of those errors are "fatal". So I think that in this case, an exception would be appropriate. But this will have to be done by the end user.

I think it would be interesting to focus on that a second. Now, I had little hands on experience with exceptions, so please don't burn me to the ground right away ;-) I did play with PHP5 iterators, and I think this is the perfect example why exceptions are useful. Iterators are to be used in a "foreach" statement where, well, basically you can't test for a returned error. Just to make it clear, consider that the "foreach" could accept a regular array as well as an iterator. If the iterator fails, throwing an exception is the proper behavior because it cannot do its job, ie iterate. Now, a bad usage of exception, IMHO: you want to open something, let's say a database. Since the purpose of the method is to try to open it, it is normal to expect that it could fail, so throwing an exception doesn't seem appropriate. A regular error yes, exception, no. But apparently SQLLite sees it differently ;-) Continuing with the database example, let's say the developer ignores the error generated by the open() method, and queries the database. Then an exception from the query() method is the proper behavior, because the database connection is not in a stable state. However, if the query fails because of a syntax in the SQL statement, it should simply return an error... About errors: I personally like to return FALSE on error and have a side method to return the error with context and so on... I think, here it's a matter of choice and it has some drawbacks, but not so much. However, this now can easily be handled with PEAR_ErrorStack: push the error, return FALSE... Again, I have to say that I'm not 100% skilled with exceptions, but the idea that my code could jump from one block to another is not reassuring. Code jumping is prone to error and leaving blocks of code unstable. Anyone for a second helping of "GOTO:"? ;-) Some argue that it's "cool" to do this: try { bunch of code line where I don't care about exceptions } catch (Exception $e) { do something or nothing... } The problem I see is that exceptions potentially bubble up to upper layers, which could either ignore and/or recover from them... but with a potentially unstable lower layer. So to remedy this, the under layer should make sure it's leaving in a stable state when an exception is thrown, meaning rollback of whatever happened... and since you don't know at what time the exceptions was fired during the "bunch of code line", it makes it hard to rollback. As I read somewhere: "catch exceptions and handle them as soon as they occur and only (re)throw as little as you can" (rephrasing by me :-) On the other hand, exceptions ARE in PHP5, so one got to deal with it... Let's also remember that PHP is loosely typed, so a method can return anything. Java and other languages are not, hence exceptions make much more sense for them. I was thinking about all this, because it seems like there are not mixed camp about using both errors and exceptions at the same time... I'd be really disappointed if exceptions became the one and only way to handle errors in PEAR/PHP5. There is room and need for both errors and exceptions, as they are conceptually different. Errors are things that are reasonable expectable, while exceptions are with exceptional things. Ok, now, I'm tied to the post, set me on fire ;-) -Philippe