On Tue, Oct 26, 2010 at 06:27:33AM +0200, Rico Secada wrote: > On Mon, 25 Oct 2010 22:56:37 -0400 > Paul M Foster <paulf@xxxxxxxxxxxxxxxxx> wrote: > > > Bear in mind, an "error" is *never* that a query returned no data or > > data the user might consider bad. > > This is an important point. When is an "error" an actual error? When is > it something that *needs* to be logged and mailed? When it's a programmer/DBA error and cannot be recovered from. For example, the statement: SELECT * WHERE custno = 'BOBSMITH'; contains a syntax error (no table reference). That should generate a fatal error, because no such statement should ever be fired at the DBMS. The programmer should ensure his statements don't contain errors like that. And if they do, there's no way to fix it from a user's perspective. There are any of a number of other PHP errors which will generate "error" level messages which should lead to fatal errors. The code should now allow such errors. And no user input should create such errors. The programmer has to filter the user's input so that whatever he enters, it doesn't cause PHP or the DBMS to error out that way. These are just definitions of "fatal" errors from my perspective. Opinions may vary. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
