if (!open my $log_FH, '>', './testlogifle.txt') {
    print "Failure to open log file.\n";
    die "Failure to open log file.\n";
}
[download]

Note that the lexical  $log_FH in the quoted code is local to the if-block and cannot be used by anything except the open failure-handling code — probably not what GreenLantern intends. Instead, the lexical should be declared outside the block if it is ever to be used there.

Also, this might be a good occasion to use the otherwise puzzling idiom I see sometimes in bioinformatics code: wrapping the open in an unless-block:

my $log_FH;

unless (open $log_FH, '>', './testlogifle.txt') {
    print "Failure to open log file.\n";
    die "Failure to open log file.\n";
    }

do_something_with($log_FH);

...
[download]

I find that often I do want a lexically scoped file handle. Also, I often find that failure to open a file is a perfectly good reason to have both if and else blocks.

my $logfile = './testlogfile.txt';

if ( open my $log_FH, '>', $logfile ) {
    do_stuff_and_write_info_to_log_about_it( $log_FH );
} else {
    print "Failure to open log file.\n";
    die "Failure to open log file $logfile for writing.: $!\n";
}
[download]

I'm influenced by Lisp's With-Open-File forms in wanting this code to look more like:

open my $log, '>>', $logfile and do {
  # lots of stuff to log
  1;
} || do {
  print "Failed to write log file $logfile: $!\n";
  die "Failed to write log file $logfile: $!\n";
}
[download]

This has the interesting attribute that if the first do-block does not return true, the error handling block runs for it, possibly allowing multiple error types to be more-or-less gracefully handled together. For many things that's a benefit (but certainly not always)