ZF-2724: Error supression on calls to loadClass across ZF obscuring parse errors

Issue Type: Bug Created: 2008-02-24T18:20:10.000+0000 Last Updated: 2008-11-22T08:45:10.000+0000 Status: Resolved Fix version(s): - 1.8.0 (30/Apr/09)

Reporter: Mark Maynereid (mim) Assignee: Matthew Weier O'Phinney (matthew) Tags: - Zend_Loader

Related issues: - ZF-2463



Hi this relates to error suppressed calls on loadClass by numerous components. See grep -R "@Zend_Loader::loadClass" trunk|grep -v ".svn" So I thought it best to log it here.

As the grep reveals, there are a number of "@Zend_Loader::loadClass" calls across the library. I just spent 30 minutes trying to track down why I had a blank page and no error log messages.

After resorting to: echo "Got this far stabbing in the dark without a flipping error message" in umpteen files, I finally tracked it down to Zend_Db_Table_Abstract::createRow() in this case which was calling "@Zend_Loader::loadClass" on my subclassed version of Zend_Db_Table_Row and supressing the message "Parse error: syntax error, unexpected T_VARIABLE, expecting ';' " - something I'd expect to fix in a second not half an hour littering my files with markers to track it down.

Sorry if my tone sounds peeved but I'd previously been burnt by this same practice occurring in Zend_Loader itself, see:

This is really frustrating. It's like some kind of copy/paste propagated virus in ZF :D I hope this practice specifically on class loading can be stamped out once and for all. I see no reason why parse errors should ever be suppressed.


Posted by Wil Sinclair (wil) on 2008-02-25T13:33:52.000+0000

Assigning and unsetting fix version priority until this issue has been reviewed.

Posted by Joakim Nygård (jokke) on 2008-03-28T16:08:41.000+0000

I couldn't agree more - a standard library (or framework) should not, ever, silence errors on it's own (unless, possibly, they can be handled gracefully). I spent almost half an hour looking for the culprit, nummerous misplaced @s in Zend_Db_*. It makes it almost impossible to debug.

On top of this, the @ operator slows things down a great deal as this is what really happens:

$old = ini_set("error_reporting", 0); ... ini_set("error_reporting", $old);

Since I removed the @s in Zend for my current project, I could easily produce a patch if needed.

Posted by James Dempster (letssurf) on 2008-04-09T09:49:55.000+0000

Grr I just spent over an our trying to work out why my script died on $myTable->createRow($data);

It turns out my _rowClass object had a parse error in it cause I was implementing a interface that didn't quite match fully. But the dam @Zend_Loader::loadClass($this->_rowClass); on line 1126 of Zend_Db_Table_Abstract stopped me from seeing the parse error!

Hope this will get fixed soon.

Posted by old of Satoru Yoshida ( on 2008-04-23T10:53:55.000+0000

I resolved ZF-2985 today. Please tell me if ZF-2985 causes something wrong.

Posted by James Dempster (letssurf) on 2008-05-07T04:56:07.000+0000

I'd like to rise the priority of this. I'd personally like to see it raised to blocker but I start with critical.

Posted by Matthew Weier O'Phinney (matthew) on 2008-11-22T08:45:10.000+0000

Resolved in r12770; however, this represents a slight change in behavior, and is also dependent on changes introduced for ZF-2923 committed with r12769, and will not release until 1.8.0.

Have you found an issue?

See the Overview section for more details.


© 2006-2020 by Zend by Perforce. Made with by awesome contributors.

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