Re: try..catch

On Wed, 30 Aug 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 > Second that, else we'd be in the same spot we're now anyway > > -- > 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 >