Defensive Programming With AOP

From NeoWiki

OVal takes the legwork out of writing repetitive conditionals

Andrew Glover, President, Stelligent Incorporated

30 Jan 2007

While defensive programming effectively guarantees the condition of a method's input, it becomes repetitive if it is pervasive across a series of methods. This month, Andrew Glover shows you an easier way to add reusable validation constraints to your code using the power of AOP, design by contract, and a handy library called OVal.

The major downside to developer testing is that the vast majority of tests exercise sunny-day scenarios. Defects rarely occur for these situations -- it's the edge cases that usually cause problems.

What's an edge case? It's the situation where, for instance, someone passes a null value to a method not coded to handle nulls. Many developers fail to test for such scenarios because they don't make much sense. But sense or no sense, these things happen, and then a NullPointerException is thrown and your whole program blows up.

This month, I suggest a multifaceted approach to dealing with the less predictable defects in your code. Find out what happens when you combine defensive programming, design by contract, and an easy-to-use generic validation framework called OVal.

Contents 1 Exposing the enemy 2 Defensive programming 2.1 Downsides of defense 3 Design by contract 4 AOP with OVal 5 Resources 6 About the author

Exposing the enemy

The code in Listing 1 builds a class hierarchy for a given Class object (omitting java.lang.Object because everything ultimately extends it). If you look carefully, however, you'll notice a potential defect waiting to be exposed because of assumptions in the method regarding object values.

Listing 1. A method without checks for null

public static Hierarchy buildHierarchy(Class clzz){
  Hierarchy hier = new Hierarchy();
  hier.setBaseClass(clzz);
  Class superclass = clzz.getSuperclass();

  if(superclass != null && superclass.getName().equals("java.lang.Object")){
    return hier; 
  }else{      
    while((clzz.getSuperclass() != null) && 
      (!clzz.getSuperclass().getName().equals("java.lang.Object"))){
      clzz = clzz.getSuperclass();
      hier.addClass(clzz);
    }	        
    return hier;
  }
}     

Having just coded the method, I haven't yet noticed the defect, but because I'm a developer testing fanatic, I write a routine test using TestNG. What's more, I use TestNG's handy DataProvider feature, which allows me to create a generic test case and vary the parameters to it through another method. Running the test case defined in Listing 2 yields two passes! Everything is good to go, right?

Listing 2. A TestNG test verifying two values

import java.util.Vector;
import static org.testng.Assert.assertEquals;
import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;

public class BuildHierarchyTest {

  @DataProvider(name = "class-hierarchies")
  public Object[][] dataValues(){
    return new Object[][]{
      { Vector.class, new String[] 
          {"java.util.AbstractList", "java.util.AbstractCollection"} },
      { String.class, new String[] {} }
    };
  }

  @Test(dataProvider = "class-hierarchies"})
  public void verifyHierarchies(Class clzz, String[] names) throws Exception{
    Hierarchy hier = HierarchyBuilder.buildHierarchy(clzz);
    assertEquals(hier.getHierarchyClassNames(), names, "values were not equal");
  }
}

I still haven't spotted the defect, but something about the code is bothering me. What if someone inadvertently passes in a null value for the Class parameter? The call clzz.getSuperclass() in the fourth line of Listing 1 would throw a NullPointerException, wouldn't it?

Testing my theory is easy; I don't even have to start from scratch. I simply add {null, null} to the multidimensional Object array in the dataValues method of the original BuildHierarchyTest (in Listing 1) and run it again. Sure enough, I get the nasty NullPointerException shown in Figure 1:

Defensive programming

Once I've exposed the issue, my next step is to come up with a strategy for defeating it. The problem is that I can't control the kind of input this method will receive. For this type of problem, developers often employ defensive programming techniques that aim to catch potential errors before they wreak havoc.

Object verification is a classic defensive programming strategy for dealing with uncertainty. Accordingly, I add a check to verify whether clzz is null, as shown in Listing 3. If the value turns out to be null, I then throw a RuntimeException to alert everyone of the potential problem.

Listing 3. Adding a check for null

public static Hierarchy buildHierarchy(Class clzz){
  if(clzz == null){
    throw new RuntimeException("Class parameter can not be null");
  }

  Hierarchy hier = new Hierarchy();
  hier.setBaseClass(clzz);

  Class superclass = clzz.getSuperclass();

  if(superclass != null && superclass.getName().equals("java.lang.Object")){
    return hier;
  }else{
    while((clzz.getSuperclass() != null) &&
      (!clzz.getSuperclass().getName().equals("java.lang.Object"))){
      clzz = clzz.getSuperclass();
      hier.addClass(clzz);
    }
    return hier;
  }
}

Naturally, I also write a quick test case to verify my check actually averts NullPointerExceptions, as shown in Listing 4:

Listing 4. Verifying the null check

@Test(expectedExceptions={RuntimeException.class})
public void verifyHierarchyNull() throws Exception{
  Class clzz = null;
  HierarchyBuilder.buildHierarchy(null);		
}

In this case, defensive programming seems to have done the trick. But there are some downsides to relying solely on this strategy.

Downsides of defense

While defensive programming effectively guarantees the condition of one method's input, it becomes repetitive if it is pervasive across a series of methods. Those familiar with aspect oriented programming, or AOP, will recognize this as a crosscutting concern, meaning that defensive programming techniques span horizontally across a code base. Many different objects employ these semantics, yet they have nothing to do with the object itself from a purely object-oriented view.

What's more, this crosscutting concern starts to bleed into the notion of design by contract (DBC). DBC is a technique for ensuring that all the components in a system do what they're meant to do by explicitly stating each component's intended functionality and expectations of the client in its interface. In DBC speak, a component's intended functionality is known as a postcondition, which is essentially the obligation of the component, while the expectation of the client is collectively known as the precondition. What's more, in pure DBC terms, a class that abides by DBC rules has a contract with the outside world about the internal consistency that it will maintain, which is known as the class invariant.

Design by contract

I introduced the notion of DBC some time ago in an article about programming with Nice, which is an object-oriented, JRE-compatible programming language that has been formulated with an emphasis on modularity, expressiveness, and safety. Interestingly enough, Nice incorporates functional development techniques, including some of those found in aspect-oriented programming. Among other things, functional development makes it possible to specify preconditions and postconditions of a method.

While Nice supports DBC, it is fundamentally a different language from the Java™ language, which makes its incorporation into development shops somewhat challenging. Fortunately, there are libraries for the Java language that facilitate DBC. Each library has its pros and cons and even different methods for building in DBC for the Java language; however, recent additions to the field have taken advantage of AOP to facilitate weaving in DBC concerns, which essentially act as wrappers for a method.

A precondition is fired before the covered method is executed and the postcondition is fired after the method completes. One nice (not to be confused with the language!) thing about using AOP for building DBC constructs is that the constructs themselves can be turned off in environments where DBC concerns are unnecessary (just like assertions can be turned off). The real beauty of treating safety concerns in a crosscutting manner, however, is that you can effectively reuse them. And as we all know, reuse is a fundamental tenet of object-oriented programming. Isn't it slick how AOP complements OOP so nicely?

AOP with OVal

OVal is a generic validation framework that supports simple DBC constructs via AOP and specifically enables you to:

• Specify constraints for class fields and method return values
• Specify constraints for constructor parameters
• Specify constraints for method parameters

What's more, OVal comes with a host of predefined constraints, and it makes creating new ones quite easy.

Because OVal uses AspectJ's implementation of AOP to define advices for DBC notions, you must incorporate AspectJ into a project that will use OVal. The good news for people not familiar with AOP and AspectJ is that the effort is minimal and using OVal (even for creating new constraints) does not require you to actually code aspects other than a simple bootstrap one, which forces the default aspects that come with OVal to hook into your code.

Before you can create this bootstrap aspect, you'll have to download AspectJ. Specifically, you'll need to incorporate aspectjtools and aspectjrt JARs into your build to compile the required bootstrap aspect and weave it into your code.

Bootstrapping AOP

After you've downloaded AspectJ, the next step is to create an aspect that extends OVal's GuardAspect. It need not do anything itself, as I've shown in Listing 5. Make sure the file extension ends in .aj, but don't attempt to compile it with the normal javac.

Listing 5. The DefaultGuardAspect bootstrap aspect

Resources

Learn

• "In pursuit of code quality: Don't be fooled by the coverage report" (Andrew Glover, developerWorks, January 2006): Are your test coverage measurements leading you astray? Find out in this first article in the new series!
• "Test-first programming with Ruby" (Pat Eyler, developerWorks, May 2005): A simple exercise in test-first development, includes a discussion on refactoring.
• "Measure test coverage with Cobertura" (Elliotte Rusty Harold, developerWorks, May 2005): A primer on using Cobertura for test coverage measurement.
• The Java technology zone: Hundreds of articles about every aspect of Java programming.

Get products and technologies

• JavaNCSS: A source measurement suite for the Java platform.
• PMD: This popular open source tool scans Java code for problems.
• CheckStyle: Another Java analysis tool from SourceForge.

About the author

Andrew Glover is president of Stelligent Incorporated, which helps companies address software quality with effective developer testing strategies and continuous integration techniques that enable teams to monitor code quality early and often. Check out Andy's blog for a list of his publications.

"When you have learned to snatch the error code from the trap frame, it will be time for you to leave.", thus spake the master programmer.