[RFC] Autoloader Error Handling

On Fri, Nov 25, 2011 at 11:21 AM, Sebastian Krebs
krebs.seb@googlemail.comwrote:

2011/11/25 Ferenc Kovacs tyra3l@gmail.com

The problem with fatal, that you have no way (by the standard means, but
you can somehow manage it through the usage of output buffers or
register_shutdown_function, but thats ugly, and can change in the future)
to intercept and gracefully terminate your application, which is an often
needed feature.
AFAIK E_FATAL should be only used where the engine is left in an unstable
state, which isn't really true here.

Trying to interact with a non-existing class is not an unstable state?

"where the engine is left in an unstable state"
trying to interact with a non-existing class could push the application
in an unstable state, but changing E_ERROR to E_RECOVERABLE_ERROR would
give a chance for those developers/applications to gracefully terminate.

there are two situations:

1. The application is broken, thus the FATAL is appropriate

so should we change all instance of E_NOTICE, E_WARNING and E_STRICT to
E_ERROR?
usually those also mean that the code is broken...

2. The application tries to work with dynamic class names. If it doesn't
   use class_exists() before, its broken and FATAL is appropriate

same here.

I agree that trying to load an non-existing class is a bug, but E_ERROR is
not a punishment for buggy code, it is a safety measure, when there is no
safe way to give back the control to the application, because the engine
for that request is beyond repair.

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

Can we stay on topic please. At this time I count a vast number of
mails, but never has talked about the RFC.

Fact is that these three cases, how a autoloader terminates, exists in
PHP. If all these cases are useful is an other topic. Can we all agree
on this?

Am 25.11.2011 11:21, schrieb Sebastian Krebs:

2011/11/25 Ferenc Kovacs tyra3l@gmail.com

The problem with fatal, that you have no way (by the standard means,
but
you can somehow manage it through the usage of output buffers or
register_shutdown_function, but thats ugly, and can change in the
future)
to intercept and gracefully terminate your application, which is an
often
needed feature.
AFAIK E_FATAL should be only used where the engine is left in an
unstable
state, which isn't really true here.

Trying to interact with a non-existing class is not an unstable
state?

there are two situations:

1. The application is broken, thus the FATAL is appropriate
2. The application tries to work with dynamic class names. If it
   doesn't
   use class_exists() before, its broken and FATAL is appropriate

So I think that E_RECOVERABLE_ERROR would be more appropriate here,
and in

general we use E_ERROR many places where E_RECOVERABLE_ERROR would
be more
suitable, but thats another topic.

For clarification: I'm talking about the E_FATAL which currently
will be
called if none of the registered autoloaders were able to load the
requested class.

On Fri, Nov 25, 2011 at 9:56 AM, Sebastian Krebs
<krebs.seb@googlemail.com

wrote:

Hi,

Just to throw my 2 cent in: Im with Micheal. An application, that
tries to
access a class, that doesn't exists, is broken and a FATAL is
valid. This
application doesn't need try-catch, but a bugfix (and if it is
already
released: A better testing management).
On the other side an application, that makes use of dynamic class
names
should make use of class_exists() in any case. An exception after
calling
class_exists() is just bad, but the classloader cannot distinguish
between
the reasons, why it is called.

2011/11/25 Christian Kaps christian.kaps@mohiva.com

Am 25.11.2011 08:24, schrieb Michael Wallner:

https://wiki.php.net/rfc/**autoloader_error_handling<;
https://wiki.php.net/rfc/autoloader_error_handling>;

Throwing an exception or fatal error in an autoloader
absolutely does not make any sense in my eyes.
Projects doing this should step back and think a
minute about what they dare.

Mike

Hi,

how would you bring your application in a consistent state after
a class
couldn't be loaded. I do this by adding a try/catch block around
my
code.

try {
new Application();
} catch (Exception) {
// collect data
// send mail
// redirect to maintenance page
}

An other question is, if the autoloader work silent and I write:

new NotExistingClass();

I think in this case the engine will also trigger a fatal error.
So in
my
eyes it is regardless of whether it trigger a fatal error in the
autoloader
or the autoloader works silent. Both cases ends in a fatal error.
Or am
i
wrong here?

Christian

--

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

2011/11/25 Ferenc Kovacstyra3l@gmail.com

The problem with fatal, that you have no way (by the standard means, but
you can somehow manage it through the usage of output buffers or
register_shutdown_function, but thats ugly, and can change in the future)
to intercept and gracefully terminate your application, which is an often
needed feature.
AFAIK E_FATAL should be only used where the engine is left in an unstable
state, which isn't really true here.

Trying to interact with a non-existing class is not an unstable state?

there are two situations:

1. The application is broken, thus the FATAL is appropriate
2. The application tries to work with dynamic class names. If it doesn't
   use class_exists() before, its broken and FATAL is appropriate

So I think that E_RECOVERABLE_ERROR would be more appropriate here, and in

There's a third possibility.

3. The application uses a mapped or indexed autoloader and the map is
   out of date. Rebuilding the map would resolve the error.

So I could see a use for a recovery there; if new NonExistentClass
fails, try to rebuild the index and try again before fataling out entirely.

Whether that's too much of an edge case or not, I don't know, but it is
a legitimate use case. (Drupal 7 has an indexed autoloader, and we've
run into the stale index problem many times. We're trying to migrate
most code to PSR-0 for Drupal 8, but even that could use an index for
caching/performance reasons.)

--Larry Garfield

I surround my application with a try/catch block to catch uncaught
exceptions. An autoloader exception could be one of them.

But I use also similar calls to reformat error messages.

try {
$class = new ReflectionClass($annotationName);
} catch (ClassNotFoundException $e) {
$message = "The annotation class {$annotationName} cannot be
found; ";
$message .= "called in DocBlock for:
{$this->context->getLocation()}; ";
throw new ClassNotFoundException($message, null, $e);
}

How would you write the above example without the exceptions? Maybe
your solution is smarter then mine.

Am 25.11.2011 11:00, schrieb Rafael Kassner:

If your autoloader throws an exception, you need to try/catch entire
application. It doesn't sounds useful. On my view, if you want to be
mailed about an autoloader fail, this have to be coded inside of your
own single autoloader.

On Fri, Nov 25, 2011 at 7:46 AM, Christian Kaps
christian.kaps@mohiva.com wrote:

Am 25.11.2011 10:34, schrieb Rafael Kassner:

I think an autoloader can't be raise any kind of error. If the
class
will be loaded by another autoloader on the stack and the first
throws
an Exception, this will be a wrong behavior.
Indeed, if autoloader can't include the class, PHP throws a fatal
error, and you can avoid it using class_exists function that calls
autoloader by its own.

You can do this, but the engine triggers still a fatal error. The
call "new
NotExistingClass();" triggers the autoloader. The autoloader sees
that the
class doesn't exists and continues silent. And now the engine tries
to
instantiate a not existing class, which ends in a fatal error.

On Fri, Nov 25, 2011 at 6:06 AM, Christian Kaps
christian.kaps@mohiva.com wrote:

Am 25.11.2011 08:24, schrieb Michael Wallner:

https://wiki.php.net/rfc/autoloader_error_handling

Throwing an exception or fatal error in an autoloader
absolutely does not make any sense in my eyes.
Projects doing this should step back and think a
minute about what they dare.

Mike

Hi,

how would you bring your application in a consistent state after a
class
couldn't be loaded. I do this by adding a try/catch block around
my code.

try {
   new Application();
} catch (Exception) {
   // collect data
   // send mail
   // redirect to maintenance page
}

An other question is, if the autoloader work silent and I write:

new NotExistingClass();

I think in this case the engine will also trigger a fatal error.
So in my
eyes it is regardless of whether it trigger a fatal error in the
autoloader
or the autoloader works silent. Both cases ends in a fatal error.
Or am i
wrong here?

Christian

--

--
Atenciosamente,
Rafael Kassner

--

--
Atenciosamente,
Rafael Kassner