RE: [PHP-DEV] try..catch and finally From: Wez Furlong (Wez <email protected>)
Date: 08/31/00

> try..finally doesn't make much sense in the context of PHP in
> my opinion.
> At any rate, as try..* would actually be implemented in a way
> that may leak
> memory, featuring a construct that's aimed at cleaning that
> would have a
> leaking implementation makes no sense at all...

I agree about memory leaks, but "finally" is not so much geared at freeing
memory but releasing semaphores (SysV style or semaphore files) that you
might have allocated for a section of code.

The beauty is that you have access to the scope of the code you were running
so you can release a semaphore, delete a file, unlock a table or whatever
using your _local_ variables, BUT at the same time you can't make decisions
based on the type of exception: all you know is that you need to let go of
these things that might impact other processes on the machine (or perhaps on
other machines).

Yes, you can get the same effect by making your semaphore variables global,
but then you run into namespace (or maybe even recursion) issues, which is
precisely what you want to avoid if you want to reuse your code.

If recursion isn't an issue, then getting at $this in the case of an
exception thrown in an object would be the next-best thing.

Hmmm.

Another advantage of finally is that it is always called, regardless of if
there was an exception or not. This is nice because you only write your
cleanup code in one place:

$db->locktable("ATable");
try {
        ... modify contents ...
}
finally {
        /* always executed */
        $db->unlocktable("ATable");
}

is nicer (and more maintainable) than

$db->locktable("ATable");
try {
        ... modify contents ...
        $db->unlocktable("ATable");
        ... loads of cleanup code here ...
}
catch($exception) {
        $db->unlocktable("ATable");
        ... loads of cleanup code the same as above here ...
}

 
> Nobody has ever asked for this in the past either.

I understand if you don't implement a "finally" mechanism right away, but I
urge you to keep it in mind while writing the try..catch code; maybe someday
there will be hundreds of people asking for "finally" :-)

--Wez.

> Zeev
>
> At 13:38 31-08-00, Wez Furlong wrote:
> >Hi,
> >
> >Time to stick my oar in...
> >
> >I would like try .. finally, so you can clean-up resources
> before popping up
> >the
> >stack of catch handlers; something like the Delphi way.
> Conceptually, it is
> >the
> >same as a catch block that implicitly re-throws the exception:
> >
> >function do_stuff()
> >{
> > $sock = fsockopen(...);
> > try {
> > ... some code that could fail ...
> > }
> > finally {
> > /* cleanup this so we don't leak */
> > fclose($sock);
> > /* implicit throw() of the exception */
> > }
> >}
> >
> >try {
> > ... some code ...
> > do_stuff()
> > ... more code ...
> >}
> >catch($exception) {
> > ... recover ...
> >}
> >
> >I know the discussion about try/catch was that we want to
> avoid logic in the
> >exception handlers; the finally block needs the scope of
> wherever it was
> >raised
> >to be able to do the cleanup, but to prevent people checking
> to see what
> >kind of
> >exception was thrown, we don't make the actual exception
> "expression" or
> >level
> >known to the code at this point.
> >
> >All we know in the finally block is that we need to cleanup
> something we
> >allocated
> >earlier.
> >
> >Comments please.
> >
> >I would really like to see this: I tend to use finally more
> often than
> >catch.
> >
> >--Wez
> >
> >
> >
> > > -----Original Message-----
> > > From: Zeev Suraski [mailto:zeev <email protected>]
> > > Sent: 30 August 2000 21:51
> > > To: php-dev <email protected>
> > > Subject: [PHP-DEV] 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 <email protected>>
> > > http://www.zend.com/
> > >
> > >
> > > --
> > > PHP Development Mailing List <http://www.php.net/>
> > > To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
> > > For additional commands, e-mail: php-dev-help <email protected>
> > > To contact the list administrators, e-mail:
> > > php-list-admin <email protected>
> > >
> >
> >--
> >PHP Development Mailing List <http://www.php.net/>
> >To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
> >For additional commands, e-mail: php-dev-help <email protected>
> >To contact the list administrators, e-mail:
> php-list-admin <email protected>
>
> --
> Zeev Suraski <zeev <email protected>>
> http://www.zend.com/
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
> For additional commands, e-mail: php-dev-help <email protected>
> To contact the list administrators, e-mail:
> php-list-admin <email protected>
> 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>