So, ANYTHING falling under E_ALL (even E_WARNING or, gasp!, E_NOTICE) will end up raising an exception, and the session will not start. Surely this is not the desired behavior.

In my particular situation, this is a problem because I get a couple of normal/expected include warnings thrown by Zend_Loader during my unserialize callback.

Comments

Posted by Taylor Barstow (tbarstow) on 2008-04-02T08:38:45.000+0000

The fix to ZF-1325 is the source of this issue.

Posted by Ralph Schindler (ralph) on 2008-04-22T10:45:14.000+0000

This is actually the intended behavior.

In fact, Zend_Loader shouldnt be throwing warnings or errors, and there is a new verison in the incubator that supresses those issues.

I'm gonna wait on this.

--

Updating project management info.

Posted by Florian Hoenig (flo) on 2008-06-10T13:53:40.000+0000

I found the same problem. Have a custom savehandler, which uses Zend_XmlRpc_Client. This somewhere down the chain uses Zend_Validate_Hostname and for a .com address it tried to do Zend_Loader::isReadible("Zend/Validate/Hostname/Com.php"), which does not exist. isReadible tried to @fopen and surpress the warning when it does NOT exist. Which is fine, except the above error handler seems to ignore the "@" in front of the fread.

This renders Zend_XmlRpc_Client unusable within a session savehandler callback !!

ZF 1.5.2 that is. and php 5.2.1 through php 5.2.6 is what I tried. I when through all possible php.ini settings, but could not figure out how to make Zend_Session::start() respect the @ in Zend_Loader.

Any glue?

Posted by Simon R Jones (studio24) on 2008-11-02T07:17:34.000+0000

I've been looking into ZF-2900 which is related.

The underlying problem is that if a custom error handler is used then this will always receive errors, even when they are suppressed. The solution is to update the code in Zend_Session_Exception::handleSessionStartError as so:

(sigh) Sorry, everyone. It turns out it was my own dumb fault. There was a bug in our custom save handler. After two hours trying to debug this, my eyes were going cross-eyed. My apologies.

Posted by Chad Cunningham (gnarfle) on 2009-04-09T13:50:04.000+0000

So is the 1.8 suppress warnings going to fix this? And is there any chance of it being fixed in the 1.7 branch? I've hacked ZendSession to get around this which I hate doing, but this bug is a royal pain.

I'm using Doctrine with ZF, and doctrine does a lot of on the fly class generation. Zend autoloader tries to load these classes when it doesn't need to, however I can easily suppress these warnings by setting error reporting and the app works great. That is, until I try to save a Doctrine object in the session. Since Zend Session believes that I don't know what I want my error reporting to be and throws an exception for every little warning or notice, it will grind the app to a halt for a problem that I've configured the app to ignore.