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 <pa...@quillandmouse.com> 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:


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

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 M. Foster

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

Reply via email to