NYCPHP Meetup

[Adam Fields]

On Fri, Jul 25, 2003 at 10:50:17PM -0400, Jonathan Rury wrote:
> Errors are your friend but there are often better ways to handle errors than
> just allowing PHP to dump its error message to the end-user, which often is
> confusing to the person unfamiliar with PHP.
> 
> For instance, opening a database connection like this:
>   @ $db = mysql_connect($HOST, $MYSQL_USER_NAME, $MYSQL_USER_PASSWORD);
>   if (!$db)      // error connecting to database
>   {                             // inform user and provide solutions
>        echo "Error: Could not connect to database.  Please try again later.
> or contact help at blah.com;";
>        exit;
>   }
> is much better than just saying
> $db = mysql_connect($HOST, $MYSQL_USER_NAME, $MYSQL_USER_PASSWORD);
> which will continue executing the script, and waste cycles, while dumping a
> much less meaningful error message.

This is not always true. In this particular case, the error was
"invalid function: pg_pconnect" (I installed php from rpm, and hadn't
realized that there was a separate rpm for the php-pgsql connector
even though the rpm included the --with-pgsql flag). This is a fatal
error, so the page stopped execution immediately at that line. The
additional error-reporting code included after that (if there is any;
in GForge, there isn't) never gets called.

I'm reasonably familiar with PHP, and this was confusing to me.

> Good coding practice is not to ignore malformed input or errors BUT better
> coding is to respond intelligently to errors, rather than just dumping error
> messages.

Agreed, but general suppression of all error reporting is bad. PHP has
a granular (but granted, not perfect) error reporting system:

http://www.php.net/manual/en/function.error-reporting.php

Also, PHP5 is moving towards exception handling, and it seems like a
good time to bring up the distinction between exceptions and
errors. Exceptions are not the same as errors. Exceptions are
predictable boundary conditions that should be handled (file does not
exist, database is unavailable, etc...) and recovered from if
possible. Errors are typically unforeseen problems and should always
be presented to the user, albeit in as friendly a way as
possible. Typically, the right thing to do with an error is to
apologize to the user and send a detailed error log to someone who can
look at it and diagnose the problem.

-- 
				- Adam

-----
Adam Fields, Managing Partner, fields at surgam.net
Surgam, Inc. is a technology consulting firm with strong background in
delivering scalable and robust enterprise web and IT applications.
http://www.adamfields.com