my @dispatch = (
    \&first,
    \&second,
    \&third,
);

my $start = 0;
$start = $recover if $recover > $start;

foreach my $index ($start .. $#dispatch) {
    &{$dispatch[$index]};
}
[download]

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

That method had occurred to me, but in a way I think the problem would be similar from a maintenance perspective.

On the one hand, it doesn't use a goto, but on the other hand, it uses symbolic (Update: Ack! they're not symbolic, I just didn't read it right! thanks!!)coderefs. If the future maintainer isn't a perl guy (and in some cases, even if he is), he'll have a much better chance of cursing my name but still getting through it if there's something as hated and feared, but at least known as a goto, than if I stick him with something where the only clue is no strict 'refs' and some good comments.

Still, for validation of the parameter, your solution is much easier and more reliable. There is a "guaranteed" set of steps in a "guaranteed" order, and you can't just jump to any old arbitrary place in the script. From that point of view, I may go with it instead.

thanks!

MM

Actually, the list of coderefs does not use symbolic references. Using symbolic references would be something like&{"$recovery};. What I do is use hard references instead.

And, as always, you should comment any use of an advanced feature, such as coderefs, if you expect your code to be maintained by people who know less than you do. This is for every language, not just Perl.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Sounds like a good use for eval. You could even pull everything into one script:

$step_1 = 0;
$step_2 = 0;
$step_3 = 0;
$working = 1;
while( $working ) {

   eval {
        $step_1 || first();
        $step_2 || second();
        $step_3 || third();
        clean_up();
   };
   if( $@ ) {
      print STDERR $@;
   } else {
      $working = 0;
   }
}
[download]

update Err, make that $step_1 ||= first() ...

-derby

Divide the large job into a series of more managable tasks which have dependencies between them. Arrange to set up each task as an item that can be restarted at any point within the task without having damanged the ability of the task to go forward. (Basically this means writing each task such that it doesn't wipe out its initial data, and can clean up or overwrite the previous partial run.) Then set up a control table with the open tasks. In that control table you mark tasks that need to run, mark them as being run, run them, then mark them as done.

Now your script can be re-run as many times as you want, and will skip work that was already done. In fact you can even have your script do as much work as feasible on each run, skipping any trouble spots, so that after a human sees it the bulk of the work got done despite any issues. Plus as a bonus if you do this carefully you may get out of it the ability to run your script simultaneously on several machines.

I attest from personal experience that while writing everything in this fashion can be a lot of work, some small steps towards the control table and distinct transactions idea does a lot towards simplifying your overall program and making it capable of handling all sorts of complex failure modes robustly. (Something doesn't look right? Abort, send notification, then continue with other stuff it can do!)

I can also attest from personal experience that the various goto solutions offered remind me of some really bad systems that I have worked with. Sure, if you do everything just right, it might work. But it is inherently a fragile approach and leads to fragile code. Not what I want in a production system! (And no, I have not merely heard vague rumor that goto is a bad idea. Give me credit for having done more homework on the topic than that.)

What's wrong with:

my $recover = $opt_r;
first() unless $recover>1;
second() unless $recover>2;
[download]

I'd hope this was readable by anybody who knows English, without needing to know perl at all.

Incidentally, with your setup, I think that you're not going to set $rec_file_name, if your recovery flag is set, and since you've declared it with my, it's not going to be visible within the subroutines anyway.

Of course, you'd find this when writing production code: remember -w and strict are your friends :-)

use Getopt::Long;

my $RECOV_STEP = 'FTP_FILE';

my $optre = &GetOptions("-restart=s" => \$RECOV_STEP);

if ($optre == 0) {
    print "Invalid Option Processing\n";
    &usage();
}

eval {
    goto $RECOV_STEP;
};
if ($@) { die "Invalid Recovery Step '$RECOV_STEP'\n" };

FTP_FILE: {
    ### get data
    print "FTP Step Started\n";
};
LOAD_FILE: {
    ### load database with file
    print "Load Step Started\n";
};
CLEANUP: {
    ### archive data
    print "Cleanup Step Started\n";
};

sub usage {
    print "$0 -restart <STEP>\n";
}
[download]