Buy the book
Paperback · 423 pages
ISBN 978-0-12-374515-6 [US]
ISBN 978-3-89864-620-8 [DE]
WHY PROGRAMS FAIL
"The definitive book on debugging."
—WALTER F. TICHY, Professor, University Karlsruhe, Germany
WHY PROGRAMS FAIL is a book about bugs in computer programs, how to reproduce them,
how to find them, and how to fix them such that they do not occur
anymore. This book teaches a number of techniques that allow you to
debug any program in a systematic, and sometimes even elegant way.
Moreover, the techniques can widely be automated, which allows you to
let your computer do most of the debugging.
Questions this book addresses include:
Once you understand how debugging works, you won't think about
debugging in the same way. Instead of seeing a wild mess of code, you
will think about causes and effects, and you will systematically set
up and refine hypotheses to track failure causes. Your insights may
even make you set up your own automated debugging tool. All of this
allows you to spend less time on debugging, which is why you're
interested in automated debugging in the first place, right?
- How can I reproduce failures faithfully?
- How can I isolate automatically what's relevant for the failure?
- How does the failure come to be?
- How can I fix the program in the best possible way?
What is new in this second edition?
In the past three years, the field of automated debugging has made tremendous advances. This second edition treats some of the most exciting novelties:
Despite these additions, the numbering of chapters, sections, and exercises is virtually unchanged. Thus, references to items in the first edition should also apply to this second edition (which is helpful if you use this book in a course).
- A new chapter on "Learning from Mistakes". In Chapter 16, I describe recent work on leveraging change and bug databases, to detect automatically where previous defects were located, and how to predict where the next ones will be.
- New insights on how to report problems. Chapter 2 now includes insights from a ground-breaking study by Bettenburg et al., who have surveyed what developers need most in a problem report.
- Reproducing crashes. In Chapter 4, I present the Cdd and ReCrash tools, which allow for automatic reproduction of crashes while requiring little to no overhead. This addresses one of the most pressing problems in debugging.
- New material on tracking origins. Chapter 9 now discusses the WHYLINE tool for JAVA , allowing expert developers to ask questions on why specific things happened during execution or why they did not ("Why did this error message occur?")
Updated and extended discussions all over the book. Along with several updates on the state of the art, I have also fixed all errors reported from readers, and revised and updated all the material.
Want to learn more? Browse the
book reviews or the
table of contents.
Get the book at
Comments? Write to Andreas Zeller <firstname.lastname@example.org>.