Issues

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

Description

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: http://framework.zend.com/issues/browse/ZF-2463

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.

Comments

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

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.

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.

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

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

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.