Could you provide some code which reproduces your issue?

There is not {{Zend_Gdata_Calendar_Extension_EventQuery}} class in the framework. There is, however, a {{Zend_Gdata_Calendar_EventQuery}} class.

        //http://framework.zend.com/issues/browse/…
        $service = Zend_Gdata_ClientLogin::getHttpClient($email, $password, Zend_Gdata_Calendar::AUTH_SERVICE_NAME );

        if (is_a($service, 'Zend_Gdata_HttpClient'))
        {
                try {
                $service = new Zend_Gdata_Calendar($service);
                $calendars = $service->getCalendarListFeed();
                foreach($calendars as $calendar)
                {
                    if ($calendar->title == $email)
                    {
                        $query = $service->newEventQuery();  ///=> here goes the erorr
......

Could you please provide a use case example? A small snippet of the framework code without a file name and line number doesn't really help narrow down where the problem is coming from.

You can try the following code

\Zend_Loader::loadClass('Zend_Gdata');
\Zend_Loader::loadClass('Zend_Gdata_ClientLogin');
\Zend_Loader::loadClass('Zend_Gdata_Calendar');
$this->_service = \Zend_Gdata_Calendar::AUTH_SERVICE_NAME;
$this->_client  = \Zend_Gdata_ClientLogin::getHttpClient(USER, PASS, $this->_service);
$this->_client->setConfig(array('keepalive' => true));
$this->_service = new \Zend_Gdata_Calendar($this->_client);
$this->defaultQuery = $this->_service->newEventQuery();

It was reported on StackOverflow

I did some digging.

In Zend/Gdata/App.php version 1.11.11, lines 1047 to 1058:

1046             foreach ($this->_registeredPackages as $name) {
1047                  try {
1048                      // Autoloading disabled on next line for compatibility
1049                      // with magic factories. See ZF-6660.
1050                      if (!class_exists($name . '_' . $class, false)) {
1051                         require_once 'Zend/Loader.php';
1052                         @Zend_Loader::loadClass($name . '_' . $class);
1053                      }  
1054                      $foundClassName = $name . '_' . $class;
1055                      break;
1056                  } catch (Zend_Exception $e) {
1057                      // package wasn't here- continue searching
1058                  }   
1059             }

The class relies on the loader to throw a Zend_Exception if the file / class it tries to load doesn't exist, or just suppresses the error with the @ symbol.

Simplified, I have the following code:

set_error_handler('errorFunction');

function errorFunction($errno, $errstr, $errfile, $errline)
{
    throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
}

This clearly doesn't honour the error suppression, and produces the above mentioned error.

This can be fixed for a lot of users by also catching the ErrorException and doing nothing with it, just like the Zend_Exception.

The simpler fix would be to not throw (non-fatal) E_NOTICE raises as (fatal) ErrorException. That said, I don't see any problem with catching and ignoring ErrorException here, as chances are that if the file being loaded has errors we're not going to want to use it anyway.

I've attached a fix and unit test that implements the suggested workaround. Personally, I would prefer that end users not throw E_NOTICE as an exception, but that's just me. I'll leave it up to the maintainer of Zend_Gdata or the CR Team to decide if the patch should be applied to the next release.

Not throwing an exception for notices makes sense, but I see in the ZF2 code they cover all their bases just by catching the base Exception class.

It might be a better (simpler) solution than the one I proposed.

Patch applied on trunk (25062) and release-1.12 (25063)

This error still exists in 1.12.1 Zend_Gdata