« Return to Thread: Error supression on calls to loadClass across ZF obscuring parse errors
Re: Error supression on calls to loadClass across ZF obscuring parse errors
by Darby Felton
::
Rate this Message:
James Dempster wrote:
> I really can't see any slow down using the Loader from the incubator.
> I've created some small benchmarking scripts which shows to me it's just
> as fast (used the Zend_Loader::autoload() to benchmark).
>
> Would this mean all the classes that are currently doing
> @Zend_Loader::loadClass($classname); would change to
> Zend_Loader:autoload($classname); ?
> Cause I notice that only Zend_Loader:autoload(); has the error handling
> in it.
Not necessarily. The solution in the incubator is only for ZF-2923. More
would likely need to be done to solve the multiple problems related to
use of Zend_Loader.
Best regards,
Darby
>
> --
> /James
>
> On Wed, May 7, 2008 at 9:01 PM, James Dempster <letssurf@...
> <mailto:letssurf@...>> wrote:
>
> Thank you for you detailed reply.
>
> I will certainly be trying this new class and hopefully get back to
> you tomorrow.
>
> Thanks
> --
> /James
>
>
> On Wed, May 7, 2008 at 7:18 PM, Darby Felton <darby@...
> <mailto:darby@...>> wrote:
>
> Hi James,
>
> The overall problem with Zend_Loader is fairly nuanced and has
> different ramifications for people using it in various
> situations. This problem is definitely on our radar, and we are
> thinking about a reasonable solution that meets the original
> Zend Framework goal of "extreme simplicity" while enabling
> reasonable performance expectations.
>
> Basically there are two competing issues:
>
> 1) Zend_Loader::loadClass() and loadFile() do not check to see
> if a file is readable before using include_once upon it. This
> causes a warning to be issued when the file does not exist, but
> the extra time for checking whether the file is readable is not
> required using this approach. This is annoying, for example, to
> people using Zend_Loader with multiple autoloaders because of
> the extra PHP warning noise.
>
> 2) Error suppression of the above (i.e., with "@") causes any
> resulting error to be hidden. This is annoying, for example,
> when loading a user class that contains a parse error because
> the error is harder to find than if the error had not been
> suppressed.
>
> In the meantime, there is a modified version of Zend_Loader I
> made in the incubator if you want to try it out. I'd be
> particularly interested in performance benchmarks, if someone
> would have time to do such a thing, but I haven't heard about
> any such results to date.
>
> Of course, guidance and contributions from community members
> like you to help solve these issues are most appreciated! :)
>
> Best regards,
> Darby
>
>
> James Dempster wrote:
>
> Hi All,
>
> I've wasted so much time creating row classes and not
> finding out about a parse errors all because line 119 of
> Zend_Db_Table_Rowset_Abstract and it's shut up operator.
>
> See http://framework.zend.com/issues/browse/ZF-2724
>
> My application would just silently die without any errors in
> my php.log or in the output. Very very frustrating.
>
> Can some one explain to me why they are there, why there is
> such a reliance on Zend_Loader. Why can't it just try to
> create the object and have any class auto loads deal with
> it, including user auto loads. Using Zend_Loader in this way
> put a reliance on Zend_Loader and with the @ sign break my
> app without me knowing where the problem occurs.
>
> What can be done to solve this? I've tried removing the @
> sign and all seems to work fine. The same problem exists in
> other classes.
>
> --
> /James
>
>
>
> I really can't see any slow down using the Loader from the incubator.
> I've created some small benchmarking scripts which shows to me it's just
> as fast (used the Zend_Loader::autoload() to benchmark).
>
> Would this mean all the classes that are currently doing
> @Zend_Loader::loadClass($classname); would change to
> Zend_Loader:autoload($classname); ?
> Cause I notice that only Zend_Loader:autoload(); has the error handling
> in it.
Not necessarily. The solution in the incubator is only for ZF-2923. More
would likely need to be done to solve the multiple problems related to
use of Zend_Loader.
Best regards,
Darby
>
> --
> /James
>
> On Wed, May 7, 2008 at 9:01 PM, James Dempster <letssurf@...
> <mailto:letssurf@...>> wrote:
>
> Thank you for you detailed reply.
>
> I will certainly be trying this new class and hopefully get back to
> you tomorrow.
>
> Thanks
> --
> /James
>
>
> On Wed, May 7, 2008 at 7:18 PM, Darby Felton <darby@...
> <mailto:darby@...>> wrote:
>
> Hi James,
>
> The overall problem with Zend_Loader is fairly nuanced and has
> different ramifications for people using it in various
> situations. This problem is definitely on our radar, and we are
> thinking about a reasonable solution that meets the original
> Zend Framework goal of "extreme simplicity" while enabling
> reasonable performance expectations.
>
> Basically there are two competing issues:
>
> 1) Zend_Loader::loadClass() and loadFile() do not check to see
> if a file is readable before using include_once upon it. This
> causes a warning to be issued when the file does not exist, but
> the extra time for checking whether the file is readable is not
> required using this approach. This is annoying, for example, to
> people using Zend_Loader with multiple autoloaders because of
> the extra PHP warning noise.
>
> 2) Error suppression of the above (i.e., with "@") causes any
> resulting error to be hidden. This is annoying, for example,
> when loading a user class that contains a parse error because
> the error is harder to find than if the error had not been
> suppressed.
>
> In the meantime, there is a modified version of Zend_Loader I
> made in the incubator if you want to try it out. I'd be
> particularly interested in performance benchmarks, if someone
> would have time to do such a thing, but I haven't heard about
> any such results to date.
>
> Of course, guidance and contributions from community members
> like you to help solve these issues are most appreciated! :)
>
> Best regards,
> Darby
>
>
> James Dempster wrote:
>
> Hi All,
>
> I've wasted so much time creating row classes and not
> finding out about a parse errors all because line 119 of
> Zend_Db_Table_Rowset_Abstract and it's shut up operator.
>
> See http://framework.zend.com/issues/browse/ZF-2724
>
> My application would just silently die without any errors in
> my php.log or in the output. Very very frustrating.
>
> Can some one explain to me why they are there, why there is
> such a reliance on Zend_Loader. Why can't it just try to
> create the object and have any class auto loads deal with
> it, including user auto loads. Using Zend_Loader in this way
> put a reliance on Zend_Loader and with the @ sign break my
> app without me knowing where the problem occurs.
>
> What can be done to solve this? I've tried removing the @
> sign and all seems to work fine. The same problem exists in
> other classes.
>
> --
> /James
>
>
>
« Return to Thread: Error supression on calls to loadClass across ZF obscuring parse errors
| Free Forum Powered by Nabble | Forum Help |