Statement Modifiers and the `or die` Idiom

Part I · Module 3 · Chapter 3.9 · Statement Modifiers and the or die Idiom

1. A Condition After the Statement

Perl lets you put the condition at the end:

use strict;
use warnings;

my $errors = 3;

print "has errors\n" if $errors;
print "clean\n"      unless $errors;

has errors

print ... if $errors; is a statement modifier. It means the same as an if block wrapped around the one statement, and unless is its negation — "do this if the condition is false".

Two restrictions worth knowing straight away. A modifier governs exactly one statement, and you cannot attach a block or an else to it. For anything with two branches you need the block form, which is Module 8's subject.

The reason to use a modifier is readability, and it is a narrow reason: it works when the statement is the point and the condition is a qualifier. print "has errors\n" if $errors; reads as one thought. When the condition is the interesting part, put it first in a block so a reader meets it first.

The other modifiers

while, until and for also work as modifiers:

use strict;
use warnings;

my $n = 3;
print "n=$n\n" while $n-- > 0;

print "$_ " for (1 .. 4);
print "\n";

n=2
n=1
n=0
1 2 3 4

These are mostly worth recognising rather than writing. The while row shows why: $n-- returns the value before decrementing, so the test used 3 while the print used 2, and the output starts at n=2 rather than n=3. A loop whose counter changes inside its own condition is hard to read in any form, and compressing it onto one line does not help. print "$_ " for (1 .. 4); is genuinely useful and clear — $_ is from Chapter 2.12, the range operator is Chapter 3.10's, and loops proper are Module 9's.

2. The or die Idiom

This is the line you will find near the top of almost every Perl script that reads a file:

use strict;
use warnings;

my $path = "/no/such/file";

open my $fh, "<", $path or die "cannot open $path: $!\n";

print "reached the line after open\n";

cannot open /no/such/file: No such file or directory

2

Nothing on STDOUT, a specific reason on STDERR, and a non-zero exit. That is exactly what a script that cannot do its job should produce.

Three parts make it work, each from somewhere you have already been:

• open returns false on failure. Module 13 covers open properly; here it is the vehicle.
• or short-circuits, so die is evaluated only when the left side is false — Chapter 3.8 §3.
• $! holds the operating system's reason, from Chapter 2.12. It is what turns "could not open the file" into "No such file or directory", and it is the difference between a report you can act on and one you cannot.

The trailing newline on the message

die "no newline here";
die "with newline here\n";

no newline here at die-newline.pl line 1.

with newline here

A die message not ending in a newline gets at FILE line N. appended. One that ends in a newline does not.

Both forms are right in different places. For a message about your code — an internal inconsistency, an impossible branch — the file and line are what you want. For a message about the user's input or environment — a missing file, a bad argument — the location is noise, because the problem is not in your source. The idiom above uses \n for that reason.

3. Why It Must Be or and Not ||

Here is the chapter's main point, and it is a measured defect rather than a caution.

use strict;
use warnings;

my $path = "/no/such/file";

open my $fh, "<", $path || die "cannot open $path: $!\n";

print "reached the line after open\n";
print "open returned a usable handle? ";
my $line = <$fh>;
print defined($line) ? "yes, read: $line" : "no, read gave undef\n";

reached the line after open
open returned a usable handle? no, read gave undef

readline() on closed filehandle $fh at broken-open.pl line 10.

0

Exit status zero. The die never ran. The script reported success.

The grouping is the whole story, and Perl's deparser shows it rather than leaving it to be asserted:

open my $fh, '<', $p || die("died\n");

|| binds more tightly than the comma separating open's arguments, so it attached itself to $path alone — not to the open call. The expression Perl evaluated was $path || die(...). And $path is a non-empty string, so by Chapter 2.8 it is true, so || short-circuited and die was never evaluated. open received the path exactly as intended, tried to open a file that does not exist, returned false — and nothing in the program looked at that return value.

or binds more loosely than the comma, which is precisely why it works: the entire open ... call becomes its left operand without any parentheses.

Two ways to be safe

Either use or, which is what the idiom is for:

open my $fh, "<", $path or die "cannot open $path: $!\n";

Or parenthesise open's arguments, after which || binds where you expect:

open(my $fh, "<", $path) || die "cannot open $path: $!\n";

Both were run and both behave identically — message on STDERR, exit 2. The first is the form you will see in real code and the one to write.

4. What Exit Status die Produces

The run above exited 2, not 255, and the reason is worth knowing because it rules out a tempting assumption.

open failure on a missing file   -> exit 2
die with no failed system call   -> exit 255
$! set to 13, then die           -> exit 13

perldoc -f die documents the rule as, in effect: exit with $! if it is non-zero, otherwise with $? >> 8 if that is non-zero, otherwise 255. The 2 above is ENOENT — the errno for "no such file or directory" — surfacing as the process exit status.

The same documentation then adds the part that matters more than the rule:

However, as $! is the value of C's errno, which can be set by any system call, this means that the value of the exit code used by die can be non-predictable, so should not be relied upon, other than to be non-zero.

So: die exits non-zero, and you should not depend on which non-zero value. If a calling flow needs to distinguish failure modes, the script has to choose its own codes explicitly with exit, which Module 14 covers. Treating die as "exits 255" is a reasonable-sounding belief that the first missing file disproves.

5. Why This Matters in Engineering Work

A script that continues after a failed read is worse than one that crashes. It will produce a report — an empty one, or one built from whatever was in the variables — and that report will be filed. A crash with a reason on STDERR costs ten minutes; a clean exit with an empty report costs however long it takes someone to notice that a number is missing.

Exit status is the interface to every flow that calls you. A Makefile, a wrapper script and a CI job all read it and nothing else. The || die bug does not merely fail to report — it actively reports success, which is the one output no caller is defending against.

$! is what makes a failure message worth sending. "Cannot open the netlist" leads to a question. "Cannot open /proj/alu/syn/out.v: No such file or directory" leads to a fix, and often the path in the message is itself the bug. This is the practical payoff of Chapter 2.12.

And the habit that covers all three: after writing a line that can fail, check that the failure path is reachable. Run the script with the file renamed. If it does not print your message and exit non-zero, the guard is not doing anything — and that test takes one command.

6. Common Mistakes

Writing open ... || die without parentheses on open. The || binds to the last argument, die never runs, and the script exits 0.

Assuming die exits 255. It exits non-zero; the specific value depends on errno and is documented as not to be relied on.

Omitting $! from the message. You lose the reason, which is the actionable half.

Omitting the trailing \n on a message about the environment. You get at FILE line N. pointing at your source, which is not where the problem is.

Declaring a variable in a statement modifier. my $x = 5 if $cond; is documented as undefined. Declare first, then assign.

Attaching a modifier to more than one statement. It governs exactly one, and there is no else.

Using a modifier when the condition is the point. A trailing condition reads well only when the statement is what the reader needs first.

7. Exercise

Exercise 1 — the two forms, side by side. Write the correct or die version against a path that does not exist. Capture STDOUT, STDERR and the exit status separately. Then change or to ||, removing the parentheses around open's arguments, and capture all three again. Put the six results in a table.

Exercise 2 — explain the grouping. For the broken line, run perl -MO=Deparse on it and state in one sentence what || attached itself to, and why die was never evaluated.

Exercise 3 — the newline. Write two die calls, one with a trailing newline and one without, and record both messages exactly. Then say which form you would use for a missing input file and which for an impossible internal state, with a reason for each.

Exercise 4 — exit status. Make a script die because of a missing file and record its exit status. Then make one die with a plain message and no failed system call, and record that. Explain the difference, and say what you would do if a calling Makefile needed to tell two failure modes apart.

Exercise 5 — prove the guard works. Take a script that opens a file that does exist and runs correctly. Rename the file, run it again, and confirm it prints your message and exits non-zero. State in one sentence why this test is worth doing on every or die you write.

Exercise 6 — modifiers in moderation. Rewrite if ($errors > 0) { print "errors: $errors\n"; } as a statement modifier. Then rewrite print "ok\n" if $count == $expected && $status eq "DONE"; as a block. Say which of the two you find more readable in its new form and why.

8. Summary

• A statement modifier puts the condition after the statement — if, unless, while, until, for — and governs exactly one statement with no else.
• Never declare a variable in a modifier. my $x = 5 if $cond; is documented as undefined behaviour, whatever it appears to do when run.
• open ... or die "...: $!" is the idiom that stops a script after a failure it cannot recover from, and $! is what makes the message actionable.
• It must be or, not ||. || binds tighter than the comma, grabs only the last argument, never evaluates die, and lets the script exit 0.
• If you want ||, parenthesise open's arguments. Both correct forms were measured as equivalent.
• A die message ending in \n suppresses the at FILE line N. suffix. Use the newline for environment problems, omit it for bugs in your own code.
• die exits non-zero but not reliably 255 — the value comes from errno and perldoc explicitly warns against depending on it.
• Test the failure path. Rename the file and confirm the guard fires.

Chapter 3.10 turns to two operators that build things rather than test them — the range operator and the list form of the repetition operator you met in Chapter 3.3.