MeowChow                                   
               s aamecha.s a..a\u$&owag.print

#>>> DummyDestructor.pm
package DummyDestructor;
use strict;
use vars qw(@ISA @EXPORT);
require Exporter;
@ISA = qw(Exporter);
@EXPORT = qw(make_finally);

sub make_finally (\&) {
  return bless $_[0], __PACKAGE__;
}

sub DESTROY {
  $_[0]->();
}
#>>> some perl script
use DummyDestructor;
...
{
  ... code ...
  my $final = make_finally { ... code ... } # beware! 
                              # no access to @_ in finally
  ... code ...
}
[download]

A more straight-forward alternative is eval and a bare block:

sub f {
  my @return;
  ... more code ... # vars needed in "finally" must be
                    # defined here!
  eval{{
    ... and more ...
    # instead of return $retval you'd need:
      @return = $retval and last;
    ... yet more code ...
  }}
  ... do clean up stuff here ...
  die $@ if $@;
  return @return;
}
[download]

Why do you have two layers of { curly braces } delimiting the eval block?

perlsyn describes how last, redo, or next won't work (or won't do what one might expect) in if, unless, do{}, sub{}, and eval{}. last says: "Note that a block by itself is semantically identical to a loop that executes once. Thus last can be used to effect an early exit out of such a block." - a solution also described in perlsyn: "Loop control statements don't work in an if or unless, since they aren't loops. You can double the braces to make them such, though. ... This is caused by the fact that a block by itself acts as a loop that executes once".

Update: Note how in the following, the first part prints "A" and "B" (and a warning about exiting eval via last), but not "D", while the second part prints "X", "Y", and "Z".

{
    print "A\n";
    eval {
        print "B\n";
        last;
        print "C\n";
    };
    print "D\n";
}

{
    print "W\n";
    eval {{
        print "X\n";
        last;
        print "Y\n";
    }};
    print "Z\n";
}
[download]

Those are exactly the two methods I was thinking of. So what do people really do in this situation?

tie $cwd => 'main';       # the example ties in package main
{
  local $cwd = '/some/other/directory';
  # execute in /some/other/directory
}
# resume in original working directory
[download]

This technique will obviously work for other ties too; it is probably more appropriate when initialisation and finalisations are such paired opposites.

Hmm, that means that the "poping" of the local going out of scope actually assigns the saved value back to the tied variable. I would have thought that the whole symbol is pushed somewhere and restored by changing its linkage.