Zend Framework

Error supression on calls to loadClass across ZF obscuring parse errors

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 1.8.0
  • Component/s: Zend_Loader
  • Labels:
    None

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 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.

Issue Links

Activity

Hide
Wil Sinclair added a comment -

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

Show
Wil Sinclair added a comment - Assigning and unsetting fix version priority until this issue has been reviewed.
Hide
Joakim Nygård added a comment -

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.

Show
Joakim Nygård added a comment - 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.
Hide
James Dempster added a comment -

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.

Show
James Dempster added a comment - 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.
Hide
Satoru Yoshida added a comment -

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

Show
Satoru Yoshida added a comment - I resolved ZF-2985 today. Please tell me if ZF-2985 causes something wrong.
Hide
James Dempster added a comment -

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

Show
James Dempster added a comment - I'd like to rise the priority of this. I'd personally like to see it raised to blocker but I start with critical.
Hide
Matthew Weier O'Phinney added a comment -

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.

Show
Matthew Weier O'Phinney added a comment - 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.

People

Vote (11)
Watch (9)

Dates

  • Created:
    Updated:
    Resolved: