The primary reason I wrote Modern Perl: the book is to help people new to Perl write Perl well. Every decision we made editorially had to support that reason. (See Why Modern Perl Teaches OO with Moose and Why the Modern Perl Book Avoids Bareword Filehandles, for two other examples.)
The start of the book suggests that all example programs in the book will work with the environment set up by:
use Modern::Perl '2012'; use autodie;
Not everyone is a fan of either. Recently, laufeyjarson wrote Why I Dislike autodie. His first point—it changes the language—is strong and his second—it would work better if it were a core offering of Perl, rather than an extension—is even more compelling to me. The rest is preference, and as such, TIMTOWTDI applies.
I don't always use it myself, for example.
Why is it in the Modern Perl book? The most important reason is a combination of laziness and correctness: if novices apply the advice to use the pragma, Perl will handle error checking for them. This means no aping of code they might not understand fully, no opportunity for them to forget to check the result of an operation which might fail, and only consistency in the reporting of error messages.
In other words, it makes the failures they ought to be checking for apparent.
Should novices eventually learn which Perl builtins invoke systems commands and as such might fail? Yes. Should they eventually learn the value of consistent mechanisms for finding and reporting errors? By all means.
Is that the first thing they should learn?
(If you believe that the proper way to teach someone how to program is to throw a copy of K&R at them, because that's how you did it, and because anyone who doesn't have the patience to learn how manual memory management and pointers work shouldn't be a real programmer, you have a fine opinion. It's a wrong opinion and you should feel badly for holding it, but it's a fine opinion.)
For experienced programmers like you and me,
autodie is an
offered convenience. You don't have to take advantage of it, but it's available
for you to do so. You and I both know how to do what it does in multiple ways
and can decide which ways are better than others in whatever circumstances we
For someone who's just learning Perl,
autodie is a way for the
computer to take care of some of the important but no less tedious details that
are most important when things go wrong. (If I had a dollar for every time
someone failed to check that an
open succeeded, I could pay
someone to turn
autodie into a core feature.)
It also makes didactic code shorter. (If I had a tachyon for every time I read a piece of technical writing which apologized "Error checking has been left as an exercise for the reader", I could invent a time machine to go back in time and thwack the writers in the head for that sin.)
Will the modern Perl police come and take away your keyboard if you don't
autodie in your own code? Even if they existed, they wouldn't.
Yet the same way we don't let new programmers wander off and write control code
for nuclear medicine control boards or space elevator design systems
unsupervised, sometimes we should let the computer take care of some of the
details until they get the hang of things. It's not that they are incapable of
writing good error handling code. It's that they don't know yet how valuable it