Possibility to add finally to try/catch?

13 years ago by Dmitri Snytkine — view source

unread

This is another feature that we know we can live without
but those familiar with languages that have 'finally' like Java or Python
know that
it is very neat feature to have in some situations.

Basically the code inside 'finally' is guaranteed to run even if there is a
'return' inside try or catch blocks
in which case the value to be returned is remembered tempraraly, the code
inside finally block executes and then remembered value is returned.

Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

13 years ago by Kiall Mac Innes — view source

unread

+1000

This is a feature that I've always wanted in PHP, My main reason being to
reduce code duplication. eg

try {
$fh = fopen($filename);

// Do some work on the file + encounter an error.
throw new Exception();

} catch (Exception $e) {
// Log an error or something
} finally {
fclose($fh);
}

Thanks,
Kiall

On Tue, Feb 28, 2012 at 2:05 PM, Dmitri Snytkine <
dsnytkine@ultralogistics.com> wrote:

This is another feature that we know we can live without
but those familiar with languages that have 'finally' like Java or Python
know that
it is very neat feature to have in some situations.

Basically the code inside 'finally' is guaranteed to run even if there is a
'return' inside try or catch blocks
in which case the value to be returned is remembered tempraraly, the code
inside finally block executes and then remembered value is returned.

Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

13 years ago by Paul Dragoonis — view source

unread

Tried to do something the other day and had to write something a bit quirky
tht would have been super clean with a finally block.

+1000

+1000

This is a feature that I've always wanted in PHP, My main reason being to
reduce code duplication. eg

try {
$fh = fopen($filename);

// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
// Log an error or something
} finally {
fclose($fh);
}

Thanks,
Kiall

On Tue, Feb 28, 2012 at 2:05 PM, Dmitri Snytkine <
dsnytkine@ultralogistics.com> wrote:

This is another feature that we know we can live without
but those familiar with languages that have 'finally' like Java or Python
know that
it is very neat feature to have in some situations.

Basically the code inside 'finally' is guaranteed to run even if there
is a
'return' inside try or catch blocks
in which case the value to be returned is remembered tempraraly, the code
inside finally block executes and then remembered value is returned.

Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

13 years ago by Simon Schick — view source

unread

Hi, Dmitri

Great that someone's mentioning it.
I thought about that several times but did not put it in here.

This is a must-have for me. Really useful if you're working with external
resources (streams, database connection etc).
I used a destructor until now for stuff like that but there are some
situations where a destructor won't be called.
http://stackoverflow.com/questions/2385047/when-will-destruct-not-be-called-in-php

Bye
Simon

2012/2/28 Paul Dragoonis dragoonis@gmail.com

Tried to do something the other day and had to write something a bit quirky
tht would have been super clean with a finally block.

+1000

On Tue, Feb 28, 2012 at 2:22 PM, Kiall Mac Innes kiall@managedit.ie
wrote:

+1000

This is a feature that I've always wanted in PHP, My main reason being to
reduce code duplication. eg

try {
$fh = fopen($filename);

// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
// Log an error or something
} finally {
fclose($fh);
}

Thanks,
Kiall

On Tue, Feb 28, 2012 at 2:05 PM, Dmitri Snytkine <
dsnytkine@ultralogistics.com> wrote:

This is another feature that we know we can live without
but those familiar with languages that have 'finally' like Java or
Python
know that
it is very neat feature to have in some situations.

Basically the code inside 'finally' is guaranteed to run even if there
is a
'return' inside try or catch blocks
in which case the value to be returned is remembered tempraraly, the
code
inside finally block executes and then remembered value is returned.

Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

13 years ago by Ferenc Kovacs — view source

unread

On Tue, Feb 28, 2012 at 3:36 PM, Simon Schick
simonsimcity@googlemail.comwrote:

Hi, Dmitri

Great that someone's mentioning it.
I thought about that several times but did not put it in here.

This is a must-have for me. Really useful if you're working with external
resources (streams, database connection etc).
I used a destructor until now for stuff like that but there are some
situations where a destructor won't be called.

http://stackoverflow.com/questions/2385047/when-will-destruct-not-be-called-in-php

Bye
Simon

https://bugs.php.net/bug.php?id=36779

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

13 years ago by Tom Boutell — view source

unread

In many cases this can be done by refactoring to a method:

public function main()
{
$in = fopen('whatever');
$this->whereTheStuffWent($in);
fclose($in);
}

protected function whereTheStuffWent($in)
{
try {
// Do stuff that might throw an exception
} catch (Exception $e)
{
// Log it or something
}
}

The while loop case in https://bugs.php.net/bug.php?id=36779 could be
dealt with by returning a result from whereTheStuffWent and breaking
out if it's set. Not too bad. finally { } might be a little more
convenient than this I suppose:

$finished = $this->whereTheStuffWent($in);
fclose($in);
if ($finished)
{
break;
}

Tried to do something the other day and had to write something a bit quirky
tht would have been super clean with a finally block.

+1000

+1000

This is a feature that I've always wanted in PHP, My main reason being to
reduce code duplication. eg

try {
$fh = fopen($filename);

// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
// Log an error or something
} finally {
fclose($fh);
}

Thanks,
Kiall

On Tue, Feb 28, 2012 at 2:05 PM, Dmitri Snytkine <
dsnytkine@ultralogistics.com> wrote:

This is another feature that we know we can live without
but those familiar with languages that have 'finally' like Java or Python
know that
it is very neat feature to have in some situations.

Basically the code inside 'finally' is guaranteed to run even if there
is a
'return' inside try or catch blocks
in which case the value to be returned is remembered tempraraly, the code
inside finally block executes and then remembered value is returned.

Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

--

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

13 years ago by Richard Lynch — view source

unread

https://bugs.php.net/bug.php?id=36779

Not to say that "finally" shouldn't be added, but I don't think this
lock inside a loop is a particularly compelling example...

Either that loop is going to wait a whole lot for an exclusive lock at
every iteration, or the locks aren't exclusive and could be more
easily built up in an array and disposed of after the loop.

Of course, for now, we have GOTO which might be of use in these
situations. :-)

Though I'm not sure you could effectively manage the (constrained to
make wanton usage difficult) GOTO statements and targets if you need
this a lot.

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE

13 years ago by Richard Lynch — view source

unread

+1000

This is a feature that I've always wanted in PHP, My main reason being
to
reduce code duplication. eg

try {
$fh = fopen($filename);
// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
// Log an error or something

  if ($fh) fclose($fh); //many PHP file errors `NULL` out the $fh

}

} finally {
```
fclose($fh);
```
}

Another non-compelling example...

Still not saying "finally" is a bad idea.

Just want a compelling use case before I would vote...

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE

13 years ago by Arvids Godjuks — view source

unread

It's quite hard to think of a compelling example. Usually you just
write the code and realize that "Yea, a 'finally' statement would make
a lot of sense here".
I believe it's the kind of functionality that you learn to use in
time, just like __set, __get, __sleep, __wakeup. If first two are no
brainier these days, the last two to me where "wtf? does anyone use
that? Where I need them at all?!". It was like that for 3-4 years.
Until I got the code witch actually made an active use of these two
and I understood the purpose.
Same goes to finally. I remember using in JavaScript a few times, helped a lot.
And it just makes sense to add to complete the try {} catch {} finally
{} template.
My 2 cents.

2012/2/28 Richard Lynch ceo@l-i-e.com:

+1000

This is a feature that I've always wanted in PHP, My main reason being
to
reduce code duplication. eg

try {
$fh = fopen($filename);

// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
// Log an error or something

if ($fh) fclose($fh); //many PHP file errors NULL out the $fh

}

} finally {

fclose($fh);

}

Another non-compelling example...

Still not saying "finally" is a bad idea.

Just want a compelling use case before I would vote...

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE

13 years ago by Kiall Mac Innes — view source

unread

Completely agree - finally comes into its own in more complex code, the
kind of code that is quite hard to distill into a few line "compelling
example".

Yes, You could abstract the try/catch into a new (and un-needed) function
to try and emulate the behavior of finally.. Unless, for example, you
re-throw the exception after logging in the catch. But - This really is no
substitute for a native language construct

try {
$fh = fopen($filename);

// Do some work on the file + encounter an error.
throw new Exception();

} catch (Exception $e) {
$log->add(Log::ERROR, "Something went wrong", $e);

throw $e;

} finally {
fclose($fh);
}

Thanks,
Kiall

On Tue, Feb 28, 2012 at 4:12 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

It's quite hard to think of a compelling example. Usually you just
write the code and realize that "Yea, a 'finally' statement would make
a lot of sense here".
I believe it's the kind of functionality that you learn to use in
time, just like __set, __get, __sleep, __wakeup. If first two are no
brainier these days, the last two to me where "wtf? does anyone use
that? Where I need them at all?!". It was like that for 3-4 years.
Until I got the code witch actually made an active use of these two
and I understood the purpose.
Same goes to finally. I remember using in JavaScript a few times, helped a
lot.
And it just makes sense to add to complete the try {} catch {} finally
{} template.
My 2 cents.

2012/2/28 Richard Lynch ceo@l-i-e.com:
+1000

This is a feature that I've always wanted in PHP, My main reason being
to
reduce code duplication. eg

try {
$fh = fopen($filename);
// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
// Log an error or something
  if ($fh) fclose($fh); //many PHP file errors `NULL` out the $fh
}
} finally {
fclose($fh);
}
Another non-compelling example...

Still not saying "finally" is a bad idea.

Just want a compelling use case before I would vote...

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE

13 years ago by Tom Boutell — view source

unread

Yes, You could abstract the try/catch into a new (and un-needed) function
to try and emulate the behavior of finally.. Unless, for example, you
re-throw the exception after logging in the catch.

'finally' doesn't run for stuff that throws an exception not caught in
the try { } block, or an exception thrown again in the catch { } block

does it?

I would hope not, since that means "something this block of code did
not anticipate at all - another sort of exceptional situation
altogether" and really should not run any more local code, nothing
until and unless there is a catch block somewhere further up that does
catch that exception.

Assuming I'm right and 'finally' runs only for normal completion and
for exceptions actually caught by the catch { } block attached to the
same try { }, then my refactoring still behaves exactly like
'finally'.

I am not convinced the function is unnecessary, either. Decomposition
is usually a good idea (:

substitute for a native language construct

try {
$fh = fopen($filename);

// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
$log->add(Log::ERROR, "Something went wrong", $e);

throw $e;
} finally {
fclose($fh);
}

Thanks,
Kiall

On Tue, Feb 28, 2012 at 4:12 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

It's quite hard to think of a compelling example. Usually you just
write the code and realize that "Yea, a 'finally' statement would make
a lot of sense here".
I believe it's the kind of functionality that you learn to use in
time, just like __set, __get, __sleep, __wakeup. If first two are no
brainier these days, the last two to me where "wtf? does anyone use
that? Where I need them at all?!". It was like that for 3-4 years.
Until I got the code witch actually made an active use of these two
and I understood the purpose.
Same goes to finally. I remember using in JavaScript a few times, helped a
lot.
And it just makes sense to add to complete the try {} catch {} finally
{} template.
My 2 cents.

2012/2/28 Richard Lynch ceo@l-i-e.com:

+1000

This is a feature that I've always wanted in PHP, My main reason being
to
reduce code duplication. eg

try {
$fh = fopen($filename);

// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
// Log an error or something

if ($fh) fclose($fh); //many PHP file errors NULL out the $fh

}

} finally {

fclose($fh);

}

Another non-compelling example...

Still not saying "finally" is a bad idea.

Just want a compelling use case before I would vote...

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:

https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE

--

--

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

13 years ago by Kiall Mac Innes — view source

unread

On Tue, Feb 28, 2012 at 11:32 AM, Kiall Mac Innes kiall@managedit.ie
wrote:

Yes, You could abstract the try/catch into a new (and un-needed) function
to try and emulate the behavior of finally.. Unless, for example, you
re-throw the exception after logging in the catch.

'finally' doesn't run for stuff that throws an exception not caught in
the try { } block, or an exception thrown again in the catch { } block

does it?

I would hope not, since that means "something this block of code did
not anticipate at all - another sort of exceptional situation
altogether" and really should not run any more local code, nothing
until and unless there is a catch block somewhere further up that does
catch that exception.

I would indeed expect the finally to run regardless of what happens in the
catch block.

$ python

def divide(x, y):
... try:
... result = x / y
... except ZeroDivisionError:
... print "division by zero!"
... raise Exception('division by zero')
... else:
... print "result is", result
... finally:
... print "executing finally clause"
...
divide(2, 1)
result is 2
executing finally clause

divide(2, 0)
division by zero!
executing finally clause <====== The interesting part
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 6, in divide
Exception: division by zero

divide("2", "1")
executing finally clause
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in divide
TypeError: unsupported operand type(s) for /: 'str' and 'str'

13 years ago by Kiall Mac Innes — view source

unread

An an equivalent snippet of ruby..

$ irb
irb(main):001:0> def divide(x, y)
irb(main):002:1> begin
irb(main):003:2* result = x / y
irb(main):004:2> puts "result is", result
irb(main):005:2> rescue ZeroDivisionError
irb(main):006:2> puts "division by zero!"
irb(main):007:2> raise Exception('division by zero')
irb(main):008:2> ensure
irb(main):009:2* puts "executing finally clause"
irb(main):010:2> end
irb(main):011:1> end
=> nil
irb(main):012:0>
irb(main):013:0*
irb(main):014:0* divide(2, 1)
result is
2
executing finally clause
=> nil
irb(main):015:0>
irb(main):016:0* divide(2, 0)
division by zero!
executing finally clause <====== The interesting part
NoMethodError: undefined method Exception' for main:Object from (irb):7:individe'
from (irb):16
from :0
irb(main):017:0>
irb(main):018:0* divide("2", "1")
executing finally clause
NoMethodError: undefined method /' for "2":String from (irb):3:individe'
from (irb):18
from :0

Thanks,
Kiall

On Tue, Feb 28, 2012 at 11:32 AM, Kiall Mac Innes kiall@managedit.ie
wrote:

Yes, You could abstract the try/catch into a new (and un-needed)
function
to try and emulate the behavior of finally.. Unless, for example, you
re-throw the exception after logging in the catch.

'finally' doesn't run for stuff that throws an exception not caught in
the try { } block, or an exception thrown again in the catch { } block

does it?

I would hope not, since that means "something this block of code did
not anticipate at all - another sort of exceptional situation
altogether" and really should not run any more local code, nothing
until and unless there is a catch block somewhere further up that does
catch that exception.

I would indeed expect the finally to run regardless of what happens in the
catch block.

$ python

def divide(x, y):
... try:
... result = x / y
... except ZeroDivisionError:
... print "division by zero!"
... raise Exception('division by zero')
... else:
... print "result is", result
... finally:
... print "executing finally clause"
...
divide(2, 1)
result is 2
executing finally clause

divide(2, 0)
division by zero!
executing finally clause <====== The interesting part
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 6, in divide
Exception: division by zero

divide("2", "1")
executing finally clause
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in divide
TypeError: unsupported operand type(s) for /: 'str' and 'str'

13 years ago by Tom Boutell — view source

unread

OK, consider my point successfully buried in counterexamples (:

An an equivalent snippet of ruby..

$ irb
irb(main):001:0> def divide(x, y)
irb(main):002:1> begin
irb(main):003:2* result = x / y
irb(main):004:2> puts "result is", result
irb(main):005:2> rescue ZeroDivisionError
irb(main):006:2> puts "division by zero!"
irb(main):007:2> raise Exception('division by zero')
irb(main):008:2> ensure
irb(main):009:2* puts "executing finally clause"
irb(main):010:2> end
irb(main):011:1> end
=> nil
irb(main):012:0>
irb(main):013:0*
irb(main):014:0* divide(2, 1)
result is
2
executing finally clause
=> nil
irb(main):015:0>
irb(main):016:0* divide(2, 0)
division by zero!
executing finally clause <====== The interesting part
NoMethodError: undefined method Exception' for main:Object from (irb):7:individe'
from (irb):16
from :0
irb(main):017:0>
irb(main):018:0* divide("2", "1")
executing finally clause
NoMethodError: undefined method /' for "2":String from (irb):3:individe'
from (irb):18
from :0

Thanks,
Kiall

On Tue, Feb 28, 2012 at 11:32 AM, Kiall Mac Innes kiall@managedit.ie
wrote:

Yes, You could abstract the try/catch into a new (and un-needed)
function
to try and emulate the behavior of finally.. Unless, for example, you
re-throw the exception after logging in the catch.

'finally' doesn't run for stuff that throws an exception not caught in
the try { } block, or an exception thrown again in the catch { } block

does it?

I would hope not, since that means "something this block of code did
not anticipate at all - another sort of exceptional situation
altogether" and really should not run any more local code, nothing
until and unless there is a catch block somewhere further up that does
catch that exception.

I would indeed expect the finally to run regardless of what happens in the
catch block.

$ python

def divide(x, y):
... try:
... result = x / y
... except ZeroDivisionError:
... print "division by zero!"
... raise Exception('division by zero')
... else:
... print "result is", result
... finally:
... print "executing finally clause"
...
divide(2, 1)
result is 2
executing finally clause

divide(2, 0)
division by zero!
executing finally clause <====== The interesting part
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 6, in divide
Exception: division by zero

divide("2", "1")
executing finally clause
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in divide
TypeError: unsupported operand type(s) for /: 'str' and 'str'

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

13 years ago by Stas Malyshev — view source

unread

Hi!

This is another feature that we know we can live without
but those familiar with languages that have 'finally' like Java or Python
know that
it is very neat feature to have in some situations.

Last time we looked into it we couldn't make a clean implementation of
it that worked well. If anybody has good ideas about how to do it,
please provide a patch.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Kiall Mac Innes — view source

unread

On Tue, Feb 28, 2012 at 5:36 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:

Last time we looked into it we couldn't make a clean implementation of it
that worked well. If anybody has good ideas about how to do it, please
provide a patch.

Right - I don't claim, even for a moment, to have the slightly clue how
easy/hard the implementation would be.

But - I don't think that should stop the discussion, or even consensus
gathering, of whether or not the feature should be implemented. If
the consensus is that the feature is useful and will likely be accepted if
formally proposed etc - that may encourage someone to spend the time on
finding a clean and acceptable implementation!

Anyway - Just my 2c.

Kiall

(P.S. Yes - I know there was an error in my ruby example.. Luckily I caused
an exception while trying to raise an exception.. so no harm!)

13 years ago by Kris Craig — view source

unread

I'll go ahead and create an RFC for this if nobody has any objections.
Then we could link to that instead of a bug ticket.

--Kris

On Tue, Feb 28, 2012 at 10:09 AM, Kiall Mac Innes kiall@managedit.iewrote:

On Tue, Feb 28, 2012 at 5:36 PM, Stas Malyshev <smalyshev@sugarcrm.com

wrote:

Last time we looked into it we couldn't make a clean implementation of it
that worked well. If anybody has good ideas about how to do it, please
provide a patch.

Right - I don't claim, even for a moment, to have the slightly clue how
easy/hard the implementation would be.

But - I don't think that should stop the discussion, or even consensus
gathering, of whether or not the feature should be implemented. If
the consensus is that the feature is useful and will likely be accepted if
formally proposed etc - that may encourage someone to spend the time on
finding a clean and acceptable implementation!

Anyway - Just my 2c.

Kiall

(P.S. Yes - I know there was an error in my ruby example.. Luckily I caused
an exception while trying to raise an exception.. so no harm!)

13 years ago by Galen Wright-Watson — view source

unread

A userland solution is possible making use of destructors to run anonymous
functions (see How can I get around the lack of a finally block in
PHP?http://stackoverflow.com/a/9244733/90527).
However, there are a number of issues with this approach (some are outlined
in the link), and language-level support would be preferable.

As for implementation, would it be possible to hook into whatever PHP has
in the way of frame disposal? That approach would have one of the same
issues as the userland solution ("finally" blocks won't run until the
current scope is exited), but is at least a partial solution. Would it be
possible to implement partial block scope? The idea being to add some sort
of guard when entering a block with an attached "finally", so that when the
block is exited, the finally runs. Please excuse my ignorance if none of
this is viable; I'll do my homework now.

13 years ago by Stas Malyshev — view source

unread

Hi!

As for implementation, would it be possible to hook into whatever PHP has
in the way of frame disposal? That approach would have one of the same
issues as the userland solution ("finally" blocks won't run until the
current scope is exited), but is at least a partial solution. Would it be

No, "partial solution" is a no go. The solution should work like finally
is expected to work - finally block executed after the control leaves
try/catch/finally construct in any way. There are non-trivial things to
solve there - like how to correctly pass control if we have multiple
nested blocks or nested blocks inside finally, etc.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227