On 09/01/2012 06:39 PM, Anthony Ferrara wrote:
> So, while I know there's some discontent about having the core raise
> exceptions, let me ask the question differently:
>
> Without moving to exceptions, how could the current error and error
> handling mechanisms be improved to make the scenario I posted above easier.
> To make handling errors just as easy as ignoring them (or preferably
> easier)...?
>
> Thoughts?
I think there are other options here. Our current error handling isn't
all that different from how it would be if everything was an exception.
Chances are that common code isn't going to distinguish between the
exceptions anyway and they will end up just doing:
try {
file_put_contents(...);
} catch (Exception $e) {
error_log($e->getMessage());
}
Then the more aware folks will be checking their error logs and noticing
certain errors they may want to handle better and they add explicit
catches for this:
try {
file_put_contents(...);
} catch (NotWritableException $e) {
page_an_op();
} catch (Exception $e) {
error_log($e->getMessage());
}
In our current system the before and after would be:
file_put_contents(...);
And when the same aware person notices a specific condition they want to
handle they change it to:
if(!is_writable(...)) page_an_op();
else file_put_contents();
The Exception case runs extra code only when the condition happens while
our current system typically has the check before trying to do the
operation so there is an extra cost for each op, but there are cases
where you really don't want it to even try so there is some advantage
there. Of course a similar check can be added before the call in the
Exception case.
My point here is that these two systems aren't actually that different
and the try/catch approach is certainly more verbose. I would also hate
to end up in the situation where most code has a high-level generic
exception handler that spews huge meaningless stack traces as a
catch-all and so far removed from the context of the actual error that
you can't do anything intelligent about it there.
So how else could you approach it?
My biggest beef with exceptions is that often you end up catching them a
couple of levels above where the error actually occurred and you don't
have any sort of recovery context at that point. Common Lisp had the
notion of conditions and restarts to address this. I always found them a
bit cumbersome syntax-wise, but I liked the idea of condition objects
carrying the context of the error. A condition is similar to an
exception in some ways except it carries contextual data about the error
and it isn't necessarily exceptional/fatal if not handled. This
particular characteristic of condition objects appeal to me for PHP
because it would allow us to migrate everything to conditions, not just
the fatal errors, without breaking everything.
The second part of the Lisp approach is the restart. If you choose to
handle the condition you can also choose to try to gracefully recover by
passing the condition object which includes the context of the error to
an appropriate restart function that lives closer to the code that
actually caused the error. This split allows you to have catch-all type
of condition handlers without losing the ability to do context-aware
error recovery.
I would love to see a proposal from someone who understands
condition-restart systems inside out for how they might be applied to PHP.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
