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 behavior/documentations. 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 execution. 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@xxxxxxxxxxxxx on this post, which is a discussion list). -Hannes [1] http://bugs.php.net/50446 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
