Many people have suggested I use autodie. I have never been interested in the functionality it provides, and don’t use it. I think there’s primarily two reasons why that is. I might know a way to address one of them, but it’s tricky.
It’s Invisible
The first reason is that I feel it changes the language a lot, and in ways that make it really hard for a new reader to follow. If you’re reading code that has no error checking in it, as a new or even mid-level Perl author, you’ll perhaps not realize that’s bad, or that it does have error checking. That checking being hidden in “use autodie” can be somewhat difficult to see.
As part of that difficulty, using autodie makes changes to all the Perl builtins. When I need to use one, I look it up in perldoc. perldoc tells me it returns false or undef or whatever in case of an error. Except… that’s not true with autodie. While I’m a good enough programmer to remember this about my own programs, it makes it a lot harder to tell what a particular piece of Perl code will do.
I’m really unhappy with the changes to the second edition of the Modern Perl book, because it’s assuming autodie everywhere. I don’t want to give it to new Perl programmers any more because they’ll be confused, and the differences are subtle and almost entirely undocumented. I can’t recommend the new version of this otherwise useful book to anyone who isn’t an expert Perl programmer and that’s a shame.
I don’t like making large-scale, undocumented changes to the language libraries any more. At what point is it no longer Perl, but something new and different?
As an aside, I think a lot of expert Perl programmers forget that many people using Perl don’t know it has exceptions at all. I often find people who are shocked to discover it does. Some of them have even been using die for errors, and didn’t know how the whole thing works together. Professional programmers, not script kiddies. Happens all the time.
This concern of mine with autodie is actually a solvable problem. The Perl core needs to incorporate autodie, and update al the perldocs to explain it. If the perldoc for “unlink” said, “returns the number of files deleted. With autodie enabled, will die on error deleting files.” it would mean that a new author would have a chance to see what’s happening. I don’t expect this to happen, but until it does, I consider autodie too sweeping a set of changes for a module to be making.
I probably wouldn’t use it anyway, because of this second reason:
I Don’t Like Exceptions
I’ve worked in a ton of languages that use exceptions. I understand them, and I can use them. I don’t like them. I find it hard to write robust, resilient code with them. Many people like them because you can put off or ignore error handling and capture it all in one place. Your code is free of that distracting noise of error handling.
However, this means your code notices the errors in the wrong place to do anything about them, and has to pretty much fall over dead and crash. It can’t try and fix things very well. Or you can handle the exceptions very close to the place they might occur, littering your code with even more distracting and hard to read exception handling stanzas.
The most reliable and robust code I’ve ever written was about 70% error handling code. In many cases it could recover from errors or try an alternative to keep running. I find this much harder to do with exceptions, and exceptions in general much more difficult to manage.
If programmers were clamoring for a giant “ON ERROR GOTO” statement, while telling me that gotos were evil, I’d be really confused. Yet, that’s what exceptions are. Exceptions that many programmers never handle, and simply want the program to crash the first time something goes wrong. I don’t want my program to crash every time something goes wrong; I want it to log the error and keep going, or ask again or try an alternative.
If “Go To Considered Harmful” is still valid – and it seems to me to be – why is ON ERROR GOTO allowed? Isn’t that all an exception is?
I don’t know a way to change this preference of mine, and how to convince myself that it’s okay to just let things crash or to write horribly tangled code to pander to the needs of the exception handlers. So, I don’t.
Tags: Perl
I also find myself stopped using autodie except in a few situations, mostly in short scripts. It turns out to be annoying most of the time.
You manually write code to check the return value of every single system call you do; leaving literally not a single call out, ever. You know all the system calls you need to check as well as how to check each of them and diligently see to it. You aren’t bothered by that at all.
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.
Hi
I don’t like autodie either. Somehow I feel uneasy about it, part of that being the action-at-a-distance thing.
But, unlike you, my code would virtually never be oriented to recover somehow. I do want it to die, but just not with autodie, even if that sounds contradictory. Often I use Try::Tiny of course, to gracefully inform the user, otherwise just die.
There’s no one-size-fits-all….
Cheers
Ron
Hi,
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
I don’t like autodie partly for the core doc reasons you state, but also because there’s no autoconfess.
autodie does not alter behavior globally but to the file or block used only.
It does work with scope.
So basically it is safe and I think not bad to use where we want.
sokzzuka, John Be4ckstrand:I agree. I just want to point out that although the basic layer of laegnagus are simple, the higher layer engine that support a proliferation of DSLs are very complex. And the net effects of DSLs are making the overall language more complex.The reason that this higher level to be complex is because we want our language (including all kinds DSLs) to be basing on a uniform simple and robust lower layer. However, I observe in the current trend, many of us are promoting specific DSL development on top of different lower level language and often feel that the current lower level laegnagus are not good enough to support a simple engine for expressiveness of higher level DSL, therefore, we needs revolutionary new lower level language. In my opinion, following that trend will make our overall language spectrum unmanageable.
@{Christian Walde}: Quote “You manually write code to check the return value of every single system call you do; leaving literally not a single call out, ever. You know all the system calls you need to check as well as how to check each of them and diligently see to it. You aren’t bothered by that at all.”
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
[…] Why I dislike autodie (blog.laufeyjarson.com) […]