PEAR is discontinued

This is a static archive preserving historical releases and metadata. No new packages or updates will be published. For updates to existing packages, or to publish new packages, please use Composer and Packagist.

Home » PEAR » PEAR » Bug #949

Impossible to raiseError(DB_Error)

Details

Submitted2004-03-05 16:09 UTC
Frommarkus dot kalkbrenner at arcor dot de
Assignedcellog
StatusWont fix
PackagePEAR
PHP VersionIrrelevant
OSIrrelevant
Roadmaps(Not assigned)

Comments

[2004-03-05 16:09 UTC] markus dot kalkbrenner at arcor dot de

Description:
------------
There's another bug in PEAR's error handling:

If you have an existing object that inherits PEAR_Error (like an instance of DB_Error) it's impossible to raise it again using PEAR::raiseError(), if the constructor of the object doesn't support messages.

The problem is that $skipmsg is always false if the only parameter passed to raiseError is an object.

Here's a patch for PEAR.php and DB.php that solves the problem for DB_Error.

--- PEAR_original.php 2004-02-09 10:03:10.000000000 +0100
+++ PEAR.php 2004-03-05 16:40:57.000000000 +0100
@@ -490,7 +490,7 @@
$options = null,
$userinfo = null,
$error_class = null,
- $skipmsg = false)
+ /* deprecated */ $skipmsg = false)
{
// The error is yet a PEAR error object
if (is_object($message)) {
@@ -528,6 +528,7 @@
} else {
$ec = 'PEAR_Error';
}
+ eval("\$skipmsg = ! $ec::isConstructorSupportingMessage();");
if ($skipmsg) {
return new $ec($code, $mode, $options, $userinfo);
} else {
@@ -780,6 +781,12 @@
}

// }}}
+
+ function isConstructorSupportingMessage()
+ {
+ return false;
+ }
+
// {{{ getMode()

/**

--- DB_original.php 2004-03-05 16:44:32.000000000 +0100
+++ DB.php 2004-03-05 16:45:47.000000000 +0100
@@ -751,6 +751,12 @@
}
}
// }}}
+
+ function isConstructorSupportingMessage()
+ {
+ return false;
+ }
+
}

// }}}

Other classes that extend PEAR_Error and offering a constructor that doesn't support messages will have to overwrite the static method PEAR::isConstructorSupportingMessage() according to the patch above.

Another question:
Why has raiseError to create a new instance of an error object if a error object is passed to it? Isn't it easier to just return the passed object or a copy of it?

Markus Kalkbrenner

Reproduce code:
---------------
<?php
require_once("DB.php");
PEAR::setErrorHandling(PEAR_ERROR_PRINT);
PEAR::raiseError(new DB_Error());
?>

Expected result:
----------------
DB Error: unknown error

Actual result:
--------------
DB Error: DB Error: unknown error
Notice: DB Error: DB Error: unknown error in /home/markus/pear/PEAR.php on line 758
DB Error: DB Error: unknown error

[2004-03-29 15:36 UTC] markus dot kalkbrenner at arcor dot de

I made a little mistake at the patch. The method isConstructorSupportingMessage() of PEAR_Error has to return true ;-)

The patch has to be applied against PEAR 1.3 and DB 1.6.0

Here's the corrected patch:

--- PEAR_original.php 2004-02-09 10:03:10.000000000 +0100
+++ PEAR.php 2004-03-05 16:40:57.000000000 +0100
@@ -490,7 +490,7 @@
$options = null,
$userinfo = null,
$error_class = null,
- $skipmsg = false)
+ /* deprecated */ $skipmsg = false)
{
// The error is yet a PEAR error object
if (is_object($message)) {
@@ -528,6 +528,7 @@
} else {
$ec = 'PEAR_Error';
}
+ eval("\$skipmsg = ! $ec::isConstructorSupportingMessage();");
if ($skipmsg) {
return new $ec($code, $mode, $options, $userinfo);
} else {
@@ -780,6 +781,12 @@
}

// }}}
+
+ function isConstructorSupportingMessage()
+ {
+ return true;
+ }
+
// {{{ getMode()

/**

--- DB_original.php 2004-03-05 16:44:32.000000000 +0100
+++ DB.php 2004-03-05 16:45:47.000000000 +0100
@@ -751,6 +751,12 @@
}
}
// }}}
+
+ function isConstructorSupportingMessage()
+ {
+ return false;
+ }
+
}

// }}}