I’ve been more interested in programming patterns lately, partly due to the Ruby community’s recent interest — especially the Ruby Rogue podcast’s love affair with “Smalltalk Best Practice Patterns”.
I consider most of the patterns in “Smalltalk Best Practice Patterns” to be patterns “in the small” — things that are typically employed on a single line or method. The Gang Of Four patterns are more medium sized, dealing with methods and classes. The PEAA book covers architectural-scale patterns. I suppose “The Pragmatic Programmer” and similar books could (should!) be considered to be very general patterns, mostly about the practice of programming.
One type of pattern that I have not seen discussed much is debugging patterns. I’m not exactly sure why that is; probably just our general concentration on designing the program code itself. There are definitely testing patterns. But I can’t think of anything that I’ve seen that covers debugging patterns. A quick search on the Internet doesn’t turn up too much.
Anyway, a co-worker (Helena) and I were debugging recently, and were having trouble figuring out where a certain method on a certain object was being called. We came up with a really cool solution. We immediately called it a grenade, because its entire purpose is to blow up (raise an exception) and display a backtrace to show us the caller of the method that we’re looking for.
Here’s our implementation in Ruby:
module Grenade def method_under_investigation(*) raise "method_under_investigation called" end end class Xyz ... def xyz object_under_investigation.extend(Grenade) end ... end
I’m sure we could wrap that in some more semantic sugar, even going as far as making it look something like this:
class Xyz ... def xyz object_under_investigation.blow_up_when_method_called(:method_under_investigation) end ... end
I’m not sure that would really be worth it though, unless we were to add it to some sort of library.
So that’s our contribution to the (small) list of debugging patterns.