Re: Exceptions and Errors

On Mon, 12 Apr 2004, Ilia Alshanetsky wrote: > 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. Either that or uncaught exceptions should be E_WARNINGs instead of E_ERRORs. (I don't want to introduce Java's checked versus unchecked exception concept.) > For example the query method in SQLite can safely be allowed to fail > in certain instances. In other instances when you care about > failures there may be a need to implement custom handlers depending > on the nature of the error. For example if a query fails due to a > uniqness constrait, an UPDATE query would be ran while in all other > instances an error would be logged etc... Still, you shouldn't be ignoring E_WARNINGs unless you have a good reason. 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. :) Handling UNIQUEness queries is exactly the type of problem you're going to need to trap. For example: try { $db = new SQLiteDatabase('foo.db'); $db->query('INSERT...'); } catch (SQLiteException $e) { if ($e->getCode() == 19) { // UNIQUEness violation $db->query('UPDATE...'); } else { // log error error_log($e->getMessage() . ': ' . $e->getCode()); } } -adam -- adam@trachtenberg.com author of o'reilly's php cookbook avoid the holiday rush, buy your copy today!