in reply to Re^2: First attempt at bringing in file for input/output
in thread First attempt at bringing in file for input/output
...you might decide to produce cleaner output, and not die, but just exit instead
And why would you want to do "produce cleaner output" that way? Per the documentation, under normal circumstance, die prints the message to STDERR and exits with a non-zero return value. In other words, it combines your two lines of code into one easier-to-grok line of code, and it prints to STDERR (which makes more sense than printing an error message to STDOUT, which is what your code did), and doesn't require choosing a magic-number exit-code (you chose 1 for unspecified reasons). If you don't like the "at <source_file> line <number>"-part of the error message that die() produces, you can read the documentation's second paragraph and see that all you have to do to prevent that from being appended (ie, "produce cleaner output") is to end your message with a newline. Thus,
if (! defined $in) { die "Usage: $0 filename\n"; }
Of course, if the seeker, catfish1116, had followed either your two-line advice, or my one-line alternative, it would have hidden the line number from the error message. Since the seeker was already having difficulty figuring out what had gone wrong, this might have made debug even harder by hiding where the code was dying. So allowing die() to print the line number makes it easier for the programmer to debug; but, contrarily, line numbers in error messages might get in the way for helping the user of the script know what they did wrong. To make the error message more helpful to the user of the script, you could code it as
if (! defined $in) { die "Usage: $0 <filename>\n\n\tYou must supply a filename when cal +ling this script, otherwise it does not know what file to read\n"; }
In the end, the programmer needs to decide which is better: making the error message more clear to a future programmer, or making it more clear to the end user. (I'd probably recommend the latter; besides, if error messages are unique, then the programmer can search the code for the uniqueness of the message, even if line numbers aren't presented. Or, as a compromise, include the extra portion in my second example, but don't end it with the "\n", so that way it is more explanatory to the user, but still gives the line number to the programmer.)
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^4: First attempt at bringing in file for input/output
by 1nickt (Canon) on Oct 31, 2018 at 02:39 UTC |