Re: Exception misinformation

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: #define SQLITE_ERROR 1 /* SQL error or missing database */ #define SQLITE_INTERNAL 2 /* An internal logic error in SQLite */ #define SQLITE_PERM 3 /* Access permission denied */ #define SQLITE_ABORT 4 /* Callback routine requested an abort */ #define SQLITE_BUSY 5 /* The database file is locked */ #define SQLITE_LOCKED 6 /* A table in the database is locked */ #define SQLITE_NOMEM 7 /* A malloc() failed */ #define SQLITE_READONLY 8 /* Attempt to write a readonly database */ #define SQLITE_INTERRUPT 9 /* Operation terminated by sqlite_interrupt() */ #define SQLITE_IOERR 10 /* Some kind of disk I/O error occurred */ #define SQLITE_CORRUPT 11 /* The database disk image is malformed */ #define SQLITE_NOTFOUND 12 /* (Internal Only) Table or record not found */ #define SQLITE_FULL 13 /* Insertion failed because database is full */ #define SQLITE_CANTOPEN 14 /* Unable to open the database file */ #define SQLITE_PROTOCOL 15 /* Database lock protocol error */ #define SQLITE_EMPTY 16 /* (Internal Only) Database table is empty */ #define SQLITE_SCHEMA 17 /* The database schema changed */ #define SQLITE_TOOBIG 18 /* Too much data for one row of a table */ #define SQLITE_CONSTRAINT 19 /* Abort due to contraint violation */ #define SQLITE_MISMATCH 20 /* Data type mismatch */ #define SQLITE_MISUSE 21 /* Library used incorrectly */ #define SQLITE_NOLFS 22 /* Uses OS features not supported on host */ #define SQLITE_AUTH 23 /* Authorization denied */ #define SQLITE_FORMAT 24 /* Auxiliary database format error */ #define SQLITE_RANGE 25 /* 2nd parameter to sqlite_bind out of range */ #define SQLITE_NOTADB 26 /* File opened that is not a database file */ 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. Bertrand Mansion Mamasam