Why the Modern Perl Book Uses autodie


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.

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


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.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

affiliated with ModernPerl.net



About this Entry

This page contains a single entry by chromatic published on October 24, 2012 10:52 PM.

Slow Tests are a Code Smell was the previous entry in this blog.

I Stopped Parsing XML Thanks To XML::Rabbit is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Sponsored by Blender Recipe Reviews and the Trendshare how to invest guide

Powered by the Perl programming language

what is programming?