[Phplib-users] database absbtraction connect errors

[Chris J. <ch...@ch...>]

In all recent versions of PHPLIB, including the current CVS, all of the
database abstraction modules have code to check for errors when connecting
to the database.  That is, the files named db_*.inc, in method connect(),
all have code similar to this:

if (!$this->Link_ID) {
	$this->halt("connect($Host, $User, \$Password) failed.");
	return 0;
}

This is a Good Thing.  The halt() method can be extended to customize
messages to whatever format the user wants.

However, all of these methods also suffer from the same weakness:  they
call their respective PHP database connection functions with using the '@'
syntax to suppress errors.  That means if a connection fails, one also
gets the PHP error message, which may or may not have HTML wrapping it
depending on your PHP.INI setting of "html_errors".  Often the PHP errors
are not desirable and/or are not formatted in the manner the user wants.

For example, in db_pgsql.inc and db_mysql.inc:

// db_pgsql.inc
if(!$this->PConnect) {
        $this->Link_ID = pg_connect($cstr);
      } else {
        $this->Link_ID = pg_pconnect($cstr);
      } 
      if (!$this->Link_ID) {
        $this->halt("connect() failed.");
      }

// db_mysql.inc
if(!$this->PConnect) {
        $this->Link_ID = mysql_connect($Host, $User, $Password);
      } else {
        $this->Link_ID = mysql_pconnect($Host, $User, $Password);
      }
      if (!$this->Link_ID) {
        $this->halt("connect($Host, $User, \$Password) failed.");
        return 0;
      }

And they are always followed by the PHPLIB halt() method error message
anyway.

I propose to change all database abstraction modules to add the '@'
calling syntax to suppress the PHP connect errors, so that the only
error messages which appear are those explicitly chosen by the programmer
using PHPLIB.

Proposed changes to samples above would change the calls to be:
	$this->Link_ID = @pg_connect(...)
	$this->Link_ID = @pg_pconnect(...)
	$this->Link_ID = @mysql_connect(...)
etc. for all databases.

Does anyone either disagree with that proposal, or see a significant
problem with it?

-- 
    ..chris