2012/8/24 Nicolas Grekas <nicolas.grekas+...@gmail.com>:
>> **
>> The overall mood seems to be that since PHP has an error handler, everyone
>> is free to handle errors any way they want.
>> 2) When everyone starts handling errors in their own way with error
>> handlers, you can't reliably use third party code. You are in your own
>> universe.
>>
>
> I think that's the main point that makes any change to the way PHP
> currently handles errors difficult:
>
> The current behavior is to continue the execution flow (except for fatal
> errors of course) whereas an exception always breaks it. Throwing an
> exception, either in a custom or in a new internal handler, introduces a
> major portability + backward compatibility issue.
I think we should talk first over the general handling and then go
into the details (how to handle the different types of errors/warnings
etc.)
Maybe I repeat some things. What do we want?
A) Handling errors with exceptions instead error-handler
B) handling warnings/notices in some way.
That are 2 completely different things...
For A: Errors (something which stops execution) could be just handled
as an exception. I see no problem with this: If not handled, they
behave like now.
For B - the warnings etc. - I suggest something like this:
// This is pseudocode:
abstract class WarningAbstract implements Exception
{
public function __construct()
{
error_log($this->message()......);
unset($this); // I just want to say, that the exception is
destroyed in any way and so not handled any more
}
...
}
// A warning looks like this - this is created by PHP for example when
turning on E_WARNING in php.ini
class Warning extends WarningAbstract
{
}
// and when created it does this:
if (class_exists('Warning')) {
$warning = new Warning();
if (isset($warning)) {
throw $warning;
}
}
Logically, when the exception is created the constructor is called. In
this example (by default) PHP could handle a warning etc. (write
something into a error-log) and then "destructs itself", to stop the
handling. (Of course this doesn't work now, when unseting myself the
object is not unseted; I wrote this code only so that PHP-programmers
could understands what I mean.)
[Not so important: could be configured like now. If E_WARNING is
turned on in the php.ini, PHP creates the default handler for this
class itself. If not, the class doesn't exists and so nothing happens.
Or I create my own Warning class, and implement my own way to handle
the warnings.]
This has the big advantage, that we don't need to care about the
mentioned different handling of the different type of errors (see
above: A, B). I think it is important, that the way how it is done is
for every kind of error the same.
Now the details:
A file-error is defined
abstract class FileHandlerWarningAbstract extends if exists Warning //
of course "if exists" is no PHP - just to explain that it should work
as a "hint" for the compiler to create the "hierarchy"
{
}
The code to create the exception needs to recursively look up: If no
FileHandlerWarning exists it must know the "hirarchy of it's abstract"
(in this case the Warning) and look if that class exists. And so on.
So you can handle file-errors different from all other warnings
without try/catch everything. Not perfect for now, and I think a
little bit too complicated, but this is a brainstorming.
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
