in reply to Re: First attempt at bringing in file for input/output
in thread First attempt at bringing in file for input/output

Hi, 

Usage: ./exer_9_2 filename at ./exer_9_2 line 7.

[download]
What is this current error telling me?

You're obviously serious about learning to program, so you'll want to start more becoming pedantic right away :-)

That's not an error, that's a message. The error was when you pressed [Enter] after only typing "./exer_9_2".

The message is being emitted by the die command on line 7. The message tells you that fact, with its last part "at ./exer_9_2 line 7" showing filename and line. Perl is just that awesome.

The first part of the message is whatever the die command caused to be emitted. In this case, it's the value of the expression Usage: $0 filename. Hopefully you know (since you put it in your code) that $0 resolves to the current filename. So that's why the message names the file twice.

Knowing all that, you might decide to produce cleaner output, and not die, but just exit instead. 

if (! defined $in) {
    print "Usage: $0 <filename>\n";
    exit(1);
}

[download]
(Note the use of the convention of placing an example value for an argument inside angle braces.)

Hope this helps!


The way forward always starts with a minimal test.

Replies are listed 'Best First'.
Re^3: First attempt at bringing in file for input/output
by pryrt (Abbot) on Oct 30, 2018 at 13:38 UTC
    ...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.)

[reply]
[d/l]
[select]

      Uh, ... okay.

      The way forward always starts with a minimal test.
[reply]

In Section Seekers of Perl Wisdom