Re: try..catch

All of the information that is available today to error handler functions will also be available to the catch block. Namely, the filename and line number in which the error occurred, the type of the error and the error message in case of a PHP-level error, or the exception value in case of a throw(). We'll probably not provide the context of the error though (i.e., the symbol table local to the place in which the error occurred), to prevent people implementing logic in the catch block, instead of plain error recovery. Zeev At 00:24 31/08/2000, Sterling Hughes wrote:

Ladies and gentlemen, A try..catch construct has been on my personal wish list for several months now. I've discussed it a bit with Stig Bakken a couple of months ago, and I discussed it in length with Andi today, as well as a very bright design whiz (with mostly Java background). I want to share our findings with you, and hear comments. Note, at this point we're just brainstorming. Implementation is far from being trivial, and won't happen over night. Don't expect it before Friday (*). Design Goals --------------- - Add the ability to have centralized error handling for legacy code, as well as large code portions, without having to add a very large amount of error-checking code. This refers to built-in functions. - Add the ability to bail out from heavily nested methods/functions, without having to pass along return values all the way. The 2nd goal originates in libraries such as PEAR or PHPlib, and I think it's quite understandable. The 1st goal is what originally made me think of try..catch, and I came up with it while working on the error callback overriding code. To clarify, what I mean with this goal is that today, more often than not, people neglect to implement proper error handling, because error handling can easily increase the code size and complexity by a good 50% or so, for instance, in typical SQL code (basically, an if check for every SQL function call, to ensure it succeeded). While in C or Java, there's no excuse for such a behavior, in my opinion, PHP is a bit different in that regard. Often people won't care what goes wrong, but want to bail out nicely in case something does go wrong. In that case, an easy-to-use language-level, nestable error-overriding mechanism, would easily enable them to guard against any possible messup. Essentially, what I'm talking about is that the try..catch mechanism should be connected to the error mechanism of PHP. Suggested Behavior ----------------------- - A new construct will be introduced: try stmt catch stmt; - The catch sub-statement will NOT specify any particular type of exception that it wants to catch. It'll catch any and all exceptions. - Every recoverable PHP-level error (i.e., any error that is currently trappable via set_error_handler()) will be considered as an exception, and will trigger the catch block, if inside a try statement. - It will be possible to specify in the catch block that it didn't not properly handle the exception, and that it should propagate upwards through the call stack. In other words, try..catch will be nestable. - Another new construct will be introduced, throw(), which will enable people to trigger an exception, and attach an object (or any valid expression) to it. The catch block will be able to access this object easily. - Once the exception is handled, execution will continue from *after* the try..catch block in which the exception occurred (i.e., it won't return to the place where the exception occurred, so try..catch will not be useful to implement logic, which is good). So if I understand you correctly a sample bit of code you might have in mind would be: <?php try {

    $div = 4/0;
    print "hello world";

} catch ($exception) {

    print "An exception occurred: $exception";

} ?> output: An exception occured: Illegal division by zero. If so, it would be nice to also have the warning level placed in the local scope of the catch block (so we would know if it was E_WARNING or E_ERROR). Something like $@ (coming from Perl's special variables) or a plain variable like $level. -Sterling

-- Zeev Suraski <zeev@zend.com> http://www.zend.com/