Re^4: Multiple actions triggered by failure to open a file

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]

Give a man a fish: <%-{-{-{-<

Comment on Re^4: Multiple actions triggered by failure to open a file Select or Download Code

Replies are listed 'Best First'.
Re^5: Multiple actions triggered by failure to open a file by mr_mischief (Monsignor) on Jan 10, 2017 at 21:47 UTC
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]	[reply] [d/l]
Re^6: Multiple actions triggered by failure to open a file by Anonymous Monk on Jan 11, 2017 at 16:45 UTC
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)	[reply] [d/l]


Clear questions and runnable code get the best and fastest answer
	PerlMonks