Avdi Grimm - Exceptional Ruby

Exceptional Ruby

Copyright 2011 by Avdi Grimm. All rights reserved.

Unauthorized distribution without paying me is lame and bad for your karma. If you somehow came into a possession of this document without purchasing it, I'd really appreciate it if you'd do the decent thing and head over to http://exceptionalruby.com to buy a legit copy. Thanks!

Exceptional Ruby was written using the wonderful Org-Mode package for Emacs. The PDF edition was generated using LaTeX. Source code highlighting is by Pygments, via the LaTeX "minted" package.

The cover is by RabidDesign.

This text originated as the talk "Exceptional Ruby", which I first gave in early 2011. It contains revised and extended examples, as well as a number of completely new sections.

This book would not exist in its present form without the gracious help of a number of people.

Very special thanks go to George Anderson, who went above and beyond in providing copious, detailed proofreading notes and suggestions, constantly encouraged me, and who schooled me in the proper use of em-dashes.

Thank you to the technical reviewers who provided feedback on my early drafts: Evan Light, Jeff Casimir, Peter Cooper, Pat Maddox, Bryan Liles, and Dave Thomas.

Thanks to all of the Beta readers who bought the book in its unfinished form and thus gave me the confidence to keep working on it. Thanks especially to the Beta readers who sent me errata and other feedback: Sean Miller, Timothy Knight, Florent Guileux, Ginny Hendry, Michel Demazure, Yale Kaul.

Thank you to Jim Weirich, for sharing his failure-handling insights with me and helping clarify my thoughts on several points. Thanks to Larry Marburger, for always being around for me to bounce ideas off of. Thanks to the members of the Org-Mode mailing list for helping me with assorted LaTeX-export problems. Thanks to Robert Klemme, whose article "The Universe Between Begin and End" perfected my understanding of the else clause; and to Nick Sieger, for allowing me to reprint his code for printing out the Ruby exception heirarchy.

Thank you, finally, to my wife Stacey for being nothing but supportive of yet another project that keeps me in my office till all hours.

If I have missed anyone I sincerely apologize. Email me and I'll make sure you're included in future copies of the book.

If software were a 10-year-old's bedroom, failure handling would be the tangled mass of toys and clothes crammed hastily into the closet before Mom comes to inspect. As programmers, we know that handling errors and failures is unavoidable, and on some projects we may spend half or more of our development hours chasing down tricky failure cases. Yet dealing with failure remains an afterthought in many projects, pushed off until it can no longer be ignored, and then dealt with in a piecemeal, haphazard fashion.

In most test suites, "happy path" tests predominate, and there may only be a few token failure case tests. Software books typically relegate handling failure to brief, cursory chaptersif the topic is addressed at all. And most mature codebases are riddled with the telltale signs of hastily-patched failure casesbusiness logic that is interrupted again and again by nil-checks and begin...rescue...end blocks.

This is a book about writing software with failure in mind. It's about how to write Ruby code that takes full advantage of the language's impressive array of features for signaling and handling unexpected conditions. And it is about approaching the problem of fallible software in a more disciplined, thoughtful way.

I have two goals for this book. I hope that after reading it, you will:

1. Have a more complete understanding of the mechanics of Ruby's failure handling facilities; and
2. Be equipped with the patterns and idioms you need in order to architect a robust failure-handling strategy for your apps and libraries.

Armed with a deep understanding of Ruby's powerful exception system and a toolbox full of failure-handling techniques, your code will be more reliable and easier to understand. It will crash less often, and when problems occur it will fail more gracefully. And you'll be a happier programmer, because you'll be spending more time on writing new features and less time chasing down unexpected exceptions.