PEAR is archived and read-only

This mirror preserves historical PEAR package releases and metadata so existing references remain available.

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;
+ }
+
}

// }}}