At work, I've been building a script that will wrap around system calls to provide OS-independent file actions. It provides the ability to use defined parameters (so that things like directory names are abstracted out) and a bunch of error handling. My client loves it.

The basic design is that it will take a filename and find a list of commands to execute. It then takes each command separately, resolves the parameters, then calls a Perl module to do the actual action. (File::Copy for copy and move, Net::FTP for ftp, etc.)

Some of the parameters it allows for are FILENAME, BASENAME, and EXT so that you can do something like:

copy,abcd.txt,[BASENAME].sav
[download]

Recently, my client asked me to provide the ability to back-references. This would allow the following:

copy,abcd.txt,efgh.txt,[BASENAME].sav
compress,[2]
[download]

Not a problem, right? Well, I ran into a major issue. If I tried to resolve [2] before resolving [BASENAME].sav, my resolve code complained that [BASENAME] didn't exist. If I didn't, then how do I get [BASENAME] into [2]? Quite the conundrum ...

The solution ended up being that I needed to do my error-checking later. Do the resolutions in one sub, then check for unresolved parameters later. Much later. The error-checking code remained the same, just in a different place. (Coincedentally, it also cleaned up the resolution subroutine.)

Moral of the story? Your error-checking might be in the wrong place. Just because it doesn't deal with the standard execution path doesn't mean you can throw it in wherever you want.

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

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.