Re: try..catch

I discussed this with you once on #PHP (I'm CaPS) Uhm.. back then you said you didn't want anything like throw() .. Why did you change your mind on that? -- Mathieu On Wed, 30 Aug 2000, Zeev Suraski 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). > > > 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/ > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net >