Hello "randallgirard"

Since the bug tracker isn't really a discussion forum, lets move it to
the "General PHP User List" (which is a discussion forum).

Regarding bug#50446[1] you filed, either I am misunderstanding what
you are hoping to achieve or you are misunderstanding the expected

As far as I can tell; you are expecting the "ErrorException" class to
be some sort of magical exception which turns normal E_USER_* errors
into exceptions, without actually behaving like exceptions (i.e.
stopping program execution if not caught).

If you have a "exception handler" registered (via
set_exception_handler()) and there is no try/catch block around the
code that triggered the exception (doesn't matter where the exception
is thrown, from set_error_handler() or regular code), then the
exception handler will kick in.
After the exception handler has done its job PHP will stop the
execution of the script. No matter what.

There are no exceptions to that. On uncaught  exceptions (i.e. not
caught via catch() blocks) PHP *will* stop execution of the script.

There are multiple reasons for that, including:
 * How should PHP know where to return to?
If an exception was thrown inside an method, which was called in a
function from global scope; Where do you expect PHP to continue from?
Global scope?
>From the function that called the method?
>From the method that threw the exception?

 * Exceptions are thrown when there is something very very wrong.
If the application doesn't know how to handle that particular type of
exception (via a catch() block) then the application has no fallback
procedure in place. PHP has no other resort then to stop the execution
of the script.

 * The ErrorException isn't treated specially from PHP point of view.
Its just another exception type, like InvalidArgumentException,
ErrorExeption, BadMethodCallException, LogicException,
RuntimeException, UnexpectedValueException.
There is no technical difference between the exceptions or any other
built-in exception classes.
The built-in exceptions (SPL has a good chunk) simply suggest a
standard naming convention for exceptions to use (to simplify the
catch() clauses in applications for example).
Those exceptions will be treated just as any other exceptions, so you
must catch them if you want to deal with them and continue the script

If you want to turn all your E_USER_* errors into exceptions then you
absolutely can.
If you prefer to throw an exception when something internally emits
E_* errors (for example, invalid parameters to functions) you can.
But you still have to catch() those exceptions.

The only reason why the ErrorException exists is because many people
in the past complained over the fact PHP didn't stop execution when
internal function emitted E_* errors (such as sending array to a
function that expects an string).
Now you can throw exceptions on such errors.
Simply create an error handler and make it throw Exception
(ErrorException maps nicely to the information contained in normal E_*
errors, as it contains the "error message", "the errors code"(E_*),
"severity" (fatal error/recoverable error/warning/notice/), the
filename it occurred, and line number.
Note: You still need to catch the exception if you want to continue
the program flow.

I don't quite understand your comment about E_USER_* errors being
useless. I use those error levels extensively when I can't to inform
the caller that something happened, but "I could still do the job the
caller expected".

I personally do not use exceptions for my application flow (*I*
consider it extremely bad practice). If I want to inform the
caller/developer that something I had to guess what he wanted, or if
something skeptical/wrong happend, I throw E_USER_* errors.

My main error handler is actually the set_error_handler(). My
"default" exception handler calls back to my error handler, as my
error handler allready deals with sever error conditions.

Hope it this post shed some light on ErrorException and set_exception_handler().
If not, please "reply-to-all" with your questions (I CCed
php-general@lists.php.net on this post, which is a discussion list).


[1] http://bugs.php.net/50446

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to