BugPattern

Introduction

A BugPattern shows common mistakes at the application level. A very fine collection can be found in Eric Allens column Diagnostic Java on IBM's developerWork site. These articles are also available as a book (ISBN:1590590619).

List of BugPatterns

• The Rogue Tile -- Bug seems to be fixed, but copy and paste spread it all over the sources -- Use type system inheritance, not the copy and paste derivate. If you are brave try AspectOrientedProgramming.
• The Dangling Composite, The Null Flag -- NullPointerExceptions^? are thrown, it's not clear which part of the code is responsible -- don't consider null as a valid value, use the type system instead.
• The Double Descent -- A ClassCastException is thrown during recursion -- make only one recurrent step at a time, check your invariants.
• The Liar View -- A GUI does not show what it should (in a MVC application) -- Test the model and the view separately. For the view mock-ups are very useful. Eventually try a GUI-test framework (e.g. abbot).
• The Saboteur Data -- Input data in an invalid format crashes your application -- Always parse input data, e.g. with regular expressions (Jakarta regexp, Jakarta ORO or Java 1.4+ native regular expressions) or with a full featured parser generator (antlr), never ever specify the user behaviour.
• The Broken Dispatch -- overloading a method breaks some test cases because the wrong implementation will be called -- refine your invariants or rethink your interface (e.g use events).
• The Impostor Type -- several types are mixed into one class, distinguished by special flags, but these flags are not always interpreted correctly -- use the power of type system
• The Split Cleaner -- not all resources are cleaned (especially when an exception is thrown) -- use

   try { ... } finally {...} 

• The Fictious Implementation (part 1, part 2) -- a certain implementation of an interface breaks some invariants -- let your code check the invariants, consider automatic tools like barter or iContract.
• The Orphaned Thread -- deadlocks or thread starvation when an error occurs in one thread -- refine your inter thread communication for error signaling, consider the concurrent utilities (might become native in Java 1.5+).
• The Run-On Initialization -- not all fields of a class are initialized properly -- initialize all fields in the constructor, use a special class for uninitialized fields (not null!) or add a special uninitialized state for your class.

Discussion about BugPattern