Re: Too many "or die" clauses?

IMHO, what you have in the OP is "pretty standard fare" for making sure you know as soon as something does not go as expected (e.g. the target of a chdir fails because it happens to be an NFS path that suddenly isn't available).

I do appreciate TGI's approach, even though it looks a little more cumbersome than it really is. Another approach, if most of your "or die ..." clauses are tacked onto the same functions (system, chdir, a few others?), you could just set up a module with customized versions (and customized names) for these frequently used functions -- e.g. instead of calling "system()", use a module that you call "Safe.pm", and call "safe_system()", which would take an extra arg (either first or last) to supply a message for the "die".

BTW, I noticed, on reading the Fatal docs for the first time, that it does not support redefining/overriding the system() function, which seems to limit its value in your case.

Comment on Re: Too many "or die" clauses?

Replies are listed 'Best First'.

Re^2: Too many "or die" clauses?
by TGI (Parson) on Jun 17, 2008 at 17:00 UTC

I don't think Safe.pm is such a good choice. But otherwise, it's a good idea. Our (yours, mine and bloonix's) suggestions are pretty much the same thing--use a sub to wrap the functions--with one key difference. In mine, the data structure contains the program. In yours, the program contains the program.

I've made the arguments to the wrapper functions the same to get an apples to apples comparison.

# Program In Program (PIP)
safe_chdir('foo', 'Can't go to foo');
safe_system('foo --bar', 'foo didn\'t work');
safe_chdir('bar', 'bar is unreachable');

# Program In Data (PID)
@program = (
  [ chdir  => 'foo',       'Can't go to foo'   ],
  [ system => 'foo --bar', 'foo didn\'t work'  ],
  [ chdir  => 'bar',       'bar is unreachable' ],
);
run_program(\@program); # Hiding the dispatch and loop processing in a
+ sub.
[download]

The program in program (PIP) approach is a bit less cumbersome and simpler than the program in data (PID) method. However, with PID, you can easily modify your program by changing the data structure.

Is this a strength or a weakness of PID? It really depends on the circumstances and goals of the project. I tend to lean towards a more data driven approach, because I like the flexibility it offers. However, in a program I've been working on over the last week, I use the technique you describe.

Reflecting upon how I decide on an approach, I find that when I have a small number distinct operations (chdir and system) that must be performed many times as a group, then I use the PID style. However if I have small chunks of repeated code sprinkled around the rest of the program, then I use PIP style.

TGI says moo

[reply]
[d/l]


more useful options
	PerlMonks