[PHP] Error recovery - fatal errors

2011-05-14 Thread Tim Streater
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:

$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.

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

tim


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

Re: [PHP] mysql problems [SOLVED]

2011-05-14 Thread Curtis Maurand


Sean Greenslade wrote:


 
 [MASSIVE
SNIP]
 
 Well, from what I saw while wading through your
code, you allow
 unsanitized
 variables to be
concatenated to your queries. Big no-no! For ANY

client-generated variable, always sanitize with
mysql_real_escape_string.
 In
 fact, sanitize all your
variables. It can't hurt.
 
 Also, please don't take a
request for your entire code too literally. We
 don't like to see
pages and pages and pages of code, just the pertinent
 bits.
 --
 --Zootboy
 
 Sent from my PC.
 
Thanks to all, but it was an infinite loop.  there was a
while ($_parent != 0) { } loop.  In the loop the database
is queried.  If the returned number of rows is greater than 0 then
perform then grab a $_parent from the database.  At some point, there
must be a parent that is = 0 and the loop breaks.  However, if the
page is called with category number that doesn't exist, then the if/then
clause is never true and $_parent never gets set to 0.  I simply
added and else clause.
while ($_parent != 0)
{
  if
($num_rows  0)
   {

perform some action
   }
   else
   {
 $_parent =
0;
   }
}

and that solved the
problem.

Thank you, everyone for your help.  

Curtis


RE: [PHP] mysql problems [SOLVED]

2011-05-14 Thread Jasper Mulder

[SNIP]
 added and else clause.
 while ($_parent != 0)
 {
   if
 ($num_rows  0)
{

 perform some action
}
else
{
  $_parent =
 0;
}
 }

 and that solved the
 problem.

 Thank you, everyone for your help.

 Curtis

A small remark:
I think it is good programming practice to place such static if-clauses before 
the while statement.
This prevents a lot of redundant checks and thus saves time.

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



Re: [PHP] Error recovery - fatal errors

2011-05-14 Thread Peter Lind
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.

Regards
Peter

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

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