handling non-fatal compile-time errors

Ferenc Kovacs wrote:

ps: on a related note, somehow I got the feeling that Lester complaining
that E_STRICT errors fataling/crashing the application migrated to PHP 5.4
was related to this problem, and I'm a bit sad that we didn't managed to
figure this out back then.

I think I'm hitting the same problem here on migrating owncloud from Apache2.2
to Apache 2.4 ... The site works perfectly on 2.2 but on 2.4 we get 'white
screen' and absolutely nothing in the error logs. I've spent several hours
working my way through the 'loader' and identified point which fail, but still
not nailed why :( I suspect it's apache rewrite messing up the loaded and I'll
use your revised bug report to see if that helps track debugging!

I get the usual criticism on the owncloud lists asking why I need to change
Apache, but the answer is the same - the ISP's are moving (GoDaddy did without
any warning!) but sites simply stop working :(

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Hi,

I've just bumped into https://bugs.php.net/bug.php?id=65322 recently, and
I would like you get some opinions on the issue.
Personally I think that it is a really bad design to introduce
pedantic(E_STRICT) errors which can break basic functionality of the engine
(calling the registered autoloader), so if there is no viable solution to
make the autoloader work for these kind of errors, I would like to propose
removing the offending errors and make it a rule to not add compile-time
non-fatal errors until the problem is resolved.

ps: on a related note, somehow I got the feeling that Lester complaining
that E_STRICT errors fataling/crashing the application migrated to PHP 5.4
was related to this problem, and I'm a bit sad that we didn't managed to
figure this out back then.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

for the record this is a known(as reported) since 2007:
https://bugs.php.net/bug.php?id=42098
and reported again in 2011:
https://bugs.php.net/bug.php?id=54054&edit=2

do we agree with the resolution from the 2007, eg. it is fine that there an
undefined list of errors (from all and any error level) which behave
differently than most others (as it won't trigger the autoloader) and even
an E_STRICT error can blow up a reasonably written application (an expected
error occurs, which happens to be compile time, which will trigger the
autoloader, which will fail to autoload it's dependencies, which will
generate class not found fatal error).

I expect much more similar reports now that people start to migrate to
5.4/5.5 where E_STRICT is part of E_ALL(and that the error reporting
infrastructure in an average application is more likely to depend on
autoloading nowadays).

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Hi,

I've just bumped into https://bugs.php.net/bug.php?id=65322 recently, and
I
would like you get some opinions on the issue.
Personally I think that it is a really bad design to introduce
pedantic(E_STRICT) errors which can break basic functionality of the engine
(calling the registered autoloader), so if there is no viable solution to
make the autoloader work for these kind of errors, I would like to propose
removing the offending errors and make it a rule to not add compile-time
non-fatal errors until the problem is resolved.

I didn't look into the underlying problem with the autoloader, but just
removing the errors is not a solution. If this is so problematic we should
just drop E_STRICT and use more appropriate error types that already exist

• e.g. in the compiler E_COMPILE_WARNING can be used, which will not invoke
  a custom error handler and as such can't cause this issue. We already have
  special error types for the compiler, so why not use them?

Nikita

Hi,

I've just bumped into https://bugs.php.net/bug.php?id=65322 recently, and
I
would like you get some opinions on the issue.
Personally I think that it is a really bad design to introduce
pedantic(E_STRICT) errors which can break basic functionality of the engine
(calling the registered autoloader), so if there is no viable solution to
make the autoloader work for these kind of errors, I would like to propose
removing the offending errors and make it a rule to not add compile-time
non-fatal errors until the problem is resolved.

By the way, there is no problem per-se to allow autoloading there (nested
compilation due to error handlers is properly handled), the reason it
currently has the in_compilation check there is to prevent all the class
lookups from the compiler to trigger the autoloader (the compiler makes
extensive use of zend_lookup_class, which sets use_autoload=1). If all
lookups in the compiler are changed to use zend_lookup_class_ex with
use_autoload=0 it might be possible to remove the condition there.

Nikita