try..catch

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). Implementation ------------------- I can't say much about implementation at this point, but I can say a couple of things: - In general, implementation would be done using the existing error mechanism of Zend, and the ability to override it with different functionality in runtime. In other words, the catch block will most probably translate into an anonymous function that will be called in case of an exception. - We're trying to think of something that will not slow PHP down in case try..catch isn't being used, but the price for try..catch based code may very well be fairly high. However, it'll probably be more efficient to wrap a large block of code with a try..catch statement, than to add full error-handling code for every line in it (of course, sometimes the latter would still be better, in case you need to act differently according to the error that occurred). - In case of an exception, memory *MAY* leak under certain circumstances. Of course, it'd be a 'standard' PHP leak that would be freed at the end of the request, but this further stresses the fact that this feature would be for handling deep, unexpected non-recoverable errors, rather than implement fancy logic in a weird way. - It won't happen overnight, it may not happen in the near future at all. We just want to figure out we know what we want to do before we start figuring out how to do it exactly. Comments welcome. Zeev -- Zeev Suraski <zeev@zend.com> http://www.zend.com/