...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";
}

[download]

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";
}

[download]

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.)

In reply to Re^3: First attempt at bringing in file for input/output by pryrt
in thread First attempt at bringing in file for input/output by catfish1116

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.