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;You've probably already heard of Modern::Perl and you may have heard of 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
find ourselves.
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
use 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
is.
On the other hand, when you try to explain some things, like Unix system calls in C, if you add every error check, then you lose the actual info in the noise...
I see no way to teach students without omitting most actual error checks. Tell them each system call should be checked, explain to them the ways to do it, then go ahead and show what the code looks like *in the absence* of error checking.
The alternative is to spend the first 5 chapters of your book writing some wacky library of checked functions, then write the rest of the book in a quirky dialect with some conventions you're never ever going to see in real production code...
C's lack of exceptions does make error handling tedious, but at least with copious compiler warnings you get messages about not checking return values.
Left a comment on http://blog.laufeyjarson.com/2012/10/why-i-dislike-autodie/
actually, I'm still somewhat fuzzy about the best way to report problems for system errors. Exceptions are somewhat tricky, you don't see them, but they go EVERYWHERE (since you can't really know if you're in a try/catch until you go back up and see it).
It looks like the best way to go about it is to have functions that return a result you can check, and if you don't check the result and something goes wrong, there goes an exception.
But usually, there's not enough details in the exception proper, so by the time you get up to the catch, things may have become a complete mess already.
Talking real size programs... the problem with exceptions is pretty much summed up by Sutter's work in _Exceptional C++_. This shows how complicated it can get and what kind of ziggurat you can build if you're not really careful...
FYI: From what I remember from description Perl 6 implements mixed approach: if you don't check the result for error indication, an exception is thrown. Well, at least you can do that with _control exceptions_.
http://perlgeek.de/en/article/5-to-6#post_26
Indeed, it's probably where I picked the idea.
Perl tends to have all the cool stuff (I love yada-yada). Of course, perl6 isn't really interesting until it migrates to perl5...
Well, there is Contextual::Return by Damian Conway on CPAN, with its Failure contexts.
Version 0.4.7 though, and it does more than just control exceptions.