Re: try..catch

Will the catch block have its own scope? I think this'll be a (nasty) side effect cause an own scope would cause ppl to start writing "logic" into catch blocks on the other side.. try implementing it without its own scope.. (anonymous function, thus its own hashtable?) --CaPS On Thu, 31 Aug 2000, Zeev Suraski wrote: > 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/ > > > -- > 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 >