ZF-3684: Exception error codes are NULL in Zend_Db

Issue Type: Improvement Created: 2008-07-18T15:58:17.000+0000 Last Updated: 2011-08-28T10:14:23.000+0000 Status: Resolved Fix version(s): - 1.11.1 (30/Nov/10)

Reporter: Till Klampaeckel (till) Assignee: Pádraic Brady (padraic) Tags: - Zend_Db

  • zf-crteam-padraic
  • zf-crteam-priority

Related issues: - ZF-3216

Attachments: - ZF-3684.patch


<pre class="highlight">
const ERR_NONE = '00000';

Why are all those constants null? Parsing the error message is what this leads to and that is a pretty expensive operation. E.g. I rely on constraints set in the DB (table) on some insert operations and would like to disregard some "errors" returned. Impossible if the error code is NULL.

At least you could pass through the real error codes which the designated backend provides and allow people to match based on that. I am using Zend_Db (with PDO mysql).

I remember I had an issue open about a year or maybe 1.5 years ago describing exactly the same issues. I thought it had been fixed before.

It's only an improvement, but also a major showstopper for me.


Posted by Till Klampaeckel (till) on 2008-11-06T21:19:14.000+0000

Just adding the relation.

Posted by Till Klampaeckel (till) on 2010-08-24T15:54:36.000+0000

Hey Ralph,

can you comment what the hold up is?

I'd love to help if I know how. Otherwise the fix seems trivial, e.g.:

<pre class="highlight">
const ERR_ALREADY_EXISTS  = "ZDx00";
const ERR_CANT_MAP        = "ZDx01";
const ERR_CONSTRAINT      = "ZDx02";
const ERR_DISCONNECTED    = "ZDx03";
const ERR_MISMATCH        = "ZDx04";
const ERR_NO_PERM         = "ZDx05";
const ERR_NOT_FOUND       = "ZDx06";
const ERR_SYNTAX          = "ZDx08";
const ERR_TRUNCATED       = "ZDx09";


Posted by Marc Hodgins (mjh_ca) on 2010-11-05T00:02:03.000+0000

The constants are null because it seems they were generated from the constants defined by the PHP PDO extension in source file php-src/ext/pdo/pdo_dbh.c. The constants were not defined as enums like the other PDO constants so their values were all set to null when defined at the PHP level.

Since they're all NULL, and I don't see them being referenced anywhere in the C source except for where they are defined (as null), these can probably be safely removed from Zend_Db. They appear to serve no purpose since it doesn't appear that PDO is using these constants, and if it were, you couldn't differentiate between them anyway since they are all NULL. Comments?

Patch is attached.

Posted by Marc Hodgins (mjh_ca) on 2010-11-19T11:49:07.000+0000

Patch applied to trunk in r23404, merged to 1.11 release branch in r23405

Posted by Till Klampaeckel (till) on 2010-11-20T08:59:18.000+0000

Thanks, Marc! Appreciate it!

Posted by Till Klampaeckel (till) on 2011-08-17T20:52:06.000+0000


the ERR constants are gone?

<pre class="literal">
fgrep -r 'const ERR_' trunk/library/Zend/*
trunk/library/Zend/Captcha/ReCaptcha.php:    const ERR_CAPTCHA   = 'errCaptcha';
trunk/library/Zend/Captcha/.svn/text-base/ReCaptcha.php.svn-base:    const ERR_CAPTCHA   = 'errCaptcha';
trunk/library/Zend/Db.php:    const ERR_NONE = '00000';

Isn't that a BC break?

Posted by Marc Hodgins (mjh_ca) on 2011-08-17T21:48:34.000+0000

Till, is there a real use case where you find this has caused an actual BC break?

Per my earlier comments - they're all defined as NULL, just like in the underlying PDO driver. Therefore these constants cannot be used to differentiate between error conditions... they appear to serve no purpose at all either at the PDO driver level or at the Zend_Db level. I can't see how anyone is actually using these where their removal would cause a BC break.

This patch went in a number of versions ago and no one has raised any issues about this.

Posted by Till Klampaeckel (till) on 2011-08-21T21:59:20.000+0000

Hey Marc,

for some some reason, I don't see the constants at all though? They are not defined -- not even null.

That's my issue. I used them in my code, and now it fatals because the error constant is not there anymore.

My real use-case for 'values' of these constants was originally that parsing an error message is not very feasible. If I wanted to use PDO, I'd use it, but I use Zend_Db instead (and MySQLi). How do I tell errors apart? But using strstr, strpos or substr on the exception's message?

Does that make sense?


Posted by Till Klampaeckel (till) on 2011-08-21T22:00:57.000+0000

I also mis-understood your original comment -- even if they are null, you cannot just remove them.

That's a clear BC break. Cause now they are not there and code like this will fatal:

<pre class="highlight">


Posted by Marc Hodgins (mjh_ca) on 2011-08-23T00:33:04.000+0000

Hi Till, if you were using the removed ERR_ constants, your code was already (silently) failing or otherwise broken because these constants are all defined with the same value.

Yes, removing causes a BC break but it also fixes a 'bug' as these constants are NOT able to be used to differentiate error conditions and it is clearly misleading.

The ideal solution would be to assign values to these constants in Zend/Db.php as per the original bug description, however this won't work because of the underlying PDO extension defining these as NULL. Removing the constants alerts you to the fact that these constants should not be used as they won't behave as you expect.

Posted by Till Klampaeckel (till) on 2011-08-24T10:24:28.000+0000

Doesn't matter, it's a BC break. ZF doesn't do them in minor release for this just this reason: you break working code.

Posted by Pádraic Brady (padraic) on 2011-08-28T10:14:23.000+0000

Reverted removal of constants. BC breaks are not allowed in ZF1 unless for a critical or security issue where approval is agreed in advance with Zend.

I am additionally marking the issue as Won't Fix as the constants, while NULL, are nonetheless accurate for PDO as weird as it seems. Use at your own risk ;).

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.