In page 23 and 26 = (equal) should be changed to => (fat comma).

I would like to add a third class of people who use autodie. People who not only find adding all these checks manually a burden and error prone, but that also find that the real intent of the code becomes hidden in all the error checking. That autodie helps code clarity, because it becomes much shorter. Most pre-autodie code I’ve seen just does dies anyway (*and* forgets many of the checks – e.g. on closing a file that was opened for writing)

@dhaval: Perhaps see bug for autodie regarding autodie working in scopes.
https://rt.cpan.org/Public/Bug/Display.html?id=72053

It does work with scope.

So basically it is safe and I think not bad to use where we want.

I have to admit: I do like exceptions. But more of that: I do like a well thought exception hierarchy (exception being objects (!) of a class hierarchy on its own). Perl doesn’t have it builtin. That’s one of the reasons I looked at and programmed in Python for a while.
I think ‘autodie’ is a little bit like Moose. You can add functionality which is missing in the Perl core. Before beginners or professionals (I do know some who don’t care about error handling) don’t do error handling at all I prefer seeing them using autodie. For many scripts it is more than ok to just die on errors.
Why have I started to like exceptions. I started my career with programming in C. And I started to hate – as a defensive programmer – the whole idioms of error checking you are forced to use, like

buffer = malloc((size_t) bufferlength);
if(buffer == NULL) {
fprintf(STDERR, “ERROR: Can’t allocate memory. So what, I’ve to die, because I don’t know what I should do otherwise. Probably I should wait for console input until then administrator added hot pluggable memory to the server.\n”);
exit(1);
}

is simply tedious. And you have to write many lines of code even you are just interested in allocating memory. It would be intersting to see actual projects written in C which simply die, ehm I mean exit, on malloc errors. And that is one of the main advantage with exceptions for me. Write the code to solve the initial problem. If it’s ok that the whole program dies if something goes wrong, than you’re done with exceptions. Yes, yes, it has also a downside. Look at many java programs. If you have a typo while writing the filename you can get 50 lines of stacktrace saying more or less nothing. Just developers can interpret the deepest message as a hint on the typo. That is not the good way either. But java forces you to think about your function using other functions probably throwing exception.
I think that a good exception classification can help you to react on exceptions that may be recoverable on higher program levels and just die on others. (Yes, manually propagating low level errors to upper levels is also sooo tedious)
I have to agree that functions throwing exceptions have to be documented to act so. So when they do that suddenly, it’s not nice.

Conclusion: You CAN use autodie. You don’t need to. So it’s perfect TIMTOWTDI, the ultimative Perl dogma.

Best regards
McA

So, really, you do not need autodie and that is fine. :)

Now, there are two classes of people who do draw utility from autodie:

1. People who think the act of checking all of these calls is unnecessary burden. This might be a general attitude or simply simply the case for some scripts where the author wishes it to die if something unexpected happens.

2. People who do not know all the various calls to check and the ways to check them. For them autodie provides a way to get things done without needing to worry too much about whether they forgot to check something or without spending a few days researching and memorizing all the ways.