On 14 May 2011 12:33, Tim Streater <t...@clothears.org.uk> wrote:
> I would like, in my app, to recover from as many run-time errors as possible, 
> so that I can tidy up. And unsolicited output generated by the standard error 
> system is really unhelpful as it becomes part of the ajax reply to the 
> browser.
> So I've added my own error handler, but it seems that I can't catch fatal 
> errors. The error in question comes from doing something like:

Fatal errors are fatal - if you could recover from them, they wouldn't be fatal.

> $res = $dbh->query ($sql);
> with $sql being an SQL statement, and $dbh being a database handle. I 
> recently had a case where $dbh was NULL, which triggers a fatal error from 
> SQLite. In principle such a bug should show up quickly, but this one had lain 
> untriggered for about a year. It seems to me somewhat arbitrary for this to 
> be designated a fatal error. Is there a way I can catch these? Most SQLite 
> error situations I'm solving with try/catch but no luck with this one so far.

You've got something wrong: either $dbh is not null or the error is
not from sqlite. I'm guessing the former. To avoid situations like
that, do proper error checking (i.e. actually check that your database
connection was opened succesfully).

> Error handling in library packages seems somewhat arbitrary - e.g. opendir 
> may give an E_WARNING, but closedir, readdir don't.

You can avoid all problems with error output by turning off error
displays in php.ini (set display_errors = off) - use error logging
instead. That's the recommended setting for production servers.


WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to