Re: try..catch

That makes sense, is the psuedo-code below somewhat like your envisioning (and then setting the other variables in the local scope)? -Sterling > 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/ > >