Martin Fowler references a document by Jim Short about the advantages of the “fail fast’ behaviour.
This is the way I write my code most of the time, sometimes it feels a little paranoid, checking everything passed into a method but it helps finding bugs. In the 2.5years I’m working here at Schlund + Partner I think I had to use the debugger less then 10 times because most of the time I just have to look at the stacktrace to find the offending piece of code.
The fact that you used the debugger less then 10 times tells me that your programs are not very complex or that you use println (or a modern log4something equivalent) to debug your program. I doubt that you will find logical errors with this “fail fast” behaviour in an efficient way.
That does not mean that you should not use assertions, they are very helpful and lead to the cause of some bugs in a fast way. But this is only true for some bugs.
I don’t use a debugger because for the kind of software I develop a debugger is completly useless. It has nothing to do with complexity but with frequency of errors. You have to admit that if your system has to run a couple of days to reach a point where an error occurs, a debug is of limited use
I have to write a LOT of logging output (~3gb/day) because most of the time I am not allowed to recreate a certain situation (router failure…) which will produce the error within my system.
I admit that assertions and logging is a good way to hunt down seldomly occuring bugs. The point that you are not allowed to recreate a certain situation means that you are not allowed to test
How do you know you actually fixed the problem? And - shouldn’t you create an “offline” test for each bug popping up? This might be a good idea especially to avoid regression on your code while you are refactoring.
And - shouldn’t your code consist of several small modules that can be tested independently (and “offline”)? You don’t make any bugs in there?
Ok, should have been more clearly. I cannot recreate the ‘real’ bug cause. First thing I do after I notice a bug, is writing a unittest to reproduce the bug. Due to these excessive logs which I need to actually recreate the bug, most of the time I already have all the information needed to fix the bug, too. And if I lack something I insert logging statements, so that I will have the information, the next time a bug in this part of the code occurs. The whole problem has nothing to do with modularity, it’s the simple fact that I don’t have to use the debugger to get a certain value or see how something is executed, I already have this information in my logfile.
[...] Frank’s article about Fast fail made me think about the way to hunt for bugs o [...]