But first, let’s talk about defensive coding and how we do it. For example:

/**
 * frobs the bar and baz.
 * @param bar the bar to frob; may not be null
 * @param baz the baz to from; must be positive
 */
public String frob(String bar, int baz) {
  if (bar.length() > baz) {
    return bar.substring(baz);
  }
  else {
    return bar;
  }
}

If the contract is violated by the caller, we will get a NullPointerException or some other StringIndexOutOfBoundsException. Not too helpful. Instead, we use an internal validator helper class to provide useful messages. This is crucial for properly understanding bugs that occur in production; there’s nothing worse than coming into work to find a NullPointerException in your inbox and no clue what went wrong.

/**
 * frobs the bar and baz.
 * @param bar the bar to frob; may not be null
 * @param baz the baz to from; must be positive
 */
public String frob(String bar, int baz) {
  Validate.notNull(bar,"bar must not be null to frob");
  Validate.isTrue(baz > 0,"baz must be positive");
  if (bar.length() > baz) {
    return bar.substring(baz);
  }
  else {
    return bar;
  }
}

Validate.* methods essentially throw IllegalArgumentException if what they are checking for fails.
We use this pattern extensively, even in constructors of simple data-structure style objects. This (plus keeping this things immutable) allows users of these objects to safely rely upon the get methods behaving properly. I had need of a class to hold both a Person (representing a website user) and a Customer (representing a utility-company customer). This class (called, naturally, PersonAndCustomer), takes both objects in its constructor and requires that they are both non-null. As a further sanity check, I wanted to make sure that the Person’s customerId matched the id of the Customer that was being passed in (i.e. that they represented the same actual human in the real world):

public PersonAndCustomer(Person p, Customer c) {
  Validate.notNull(p,"Person may not be null");
  Validate.notNull(c,"Customer may not be null");
  Validate.isTrue(p.getCustomerId() == c.getId(),
    "Person %d's customer id %d didn't match passed-in customer's id %d",
    p.getId(),
    p.getCustomerId(),
    c.getId());
  ...
}

Looks pretty inocuous, right? Well, because these objects are Hibernate-managed, all of our ids are Long and not long. So, my isTrue validation is really checking that the person’s customerId object is the same object as the customer’s id object. What’s worse, in several months of development and production deployment, these two objects happened to be the same.

Until this week; we were testing our application for a new client and I got the error posted above (“Person 1001’s customer id 109032 didn’t match the passed-in customer’s id of 109032″). It seems that much like how the JVM will re-use string objects, it also will sometimes re-use boxed objects as well. But not always. The fix for this is obvious, but I wanted to make sure I could actually recreate this situation. So, I created a test that gave both the Person and Customer the same value for the customer id, but as different objects. and verified that the class could still be constructed. Sure enough, the test failed. The fix:

public PersonAndCustomer(Person p, Customer c) {
  Validate.notNull(p,"Person may not be null");
  Validate.notNull(c,"Customer may not be null");
  Validate.isTrue(p.getCustomerId().equals(c.getId()),
    "Person %d's customer id %d didn't match passed-in customer's id %d",
    p.getId(),
    p.getCustomerId(),
    c.getId());
  ...
}

What’s interesting is that if one end of the == is a primitive, the JVM will unbox the other one and the test succeeds:

Long l1 = new Long(45L);
Long l2 = new Long(45L);

System.out.println(l1 == l2);      // false
System.out.println(l1.equals(l2)); // true
System.out.println(l1 == 45L);     // true!

The moral of the story is to always know what you are comparing. Might even be best to always use .equals() unless the compiler complains.

I recently converted the attribute of our Person POJO that stored a user’s email address from a java.lang.String to a javax.mail.InternetAddress.  Call it not enough testing or lack of imagination, but I introduced a Null Pointer Exception in a back-office web flow where a new user is created for our customer service application.  When a new CSR account is created and the email address is left blank, an NPE gets thrown up.  Embarrassing, but easy to fix, right?

Just looking at the stack trace narrows it down immediately:

2009-09-09 16:56:53,636 WARN  [btpool0-1] [REPORT] [WARN] Handler execution resulted in exception
java.lang.NullPointerException
	at javax.mail.internet.InternetAddress.parse(InternetAddress.java:609)
	at javax.mail.internet.InternetAddress.parse(InternetAddress.java:569)
	at javax.mail.internet.InternetAddress.(InternetAddress.java:105)
	at poscore.db.InternetAddressUserType.deepCopy(InternetAddressUserType.java:93)
	at org.hibernate.type.CustomType.deepCopy(CustomType.java:179)
	at org.hibernate.type.TypeFactory.deepCopy(TypeFactory.java:374)

Ahh…yeah…that custom hibernate type I wrote to translate VARCHARs to InternetAddresses and vice versa. Ok, what does that deep copy method look like?

    public Object deepCopy(Object value) throws HibernateException {
        if(value == null) {
            return null;
        }
        InternetAddress original = (InternetAddress)value;
        InternetAddress copy = null;
        try {
            copy = new InternetAddress(original.getAddress());
        }
        catch (AddressException ex) {
            throw new HibernateException("Unable to deep copy email address '" + original.getAddress() + "'");
        }
        return copy;
    }

It turns out, the error is right here:

            copy = new InternetAddress(original.getAddress());

You can’t pass a null to the InternetAddress constructor. It was late in the day and I must not have internalized that there’s no way value or original could be null, because my first instinct was that the NPE was actually the result of calling “.getAddress()” on a null original object….not that the constructor can’t take a null.

While I was on that assumption (that it was the original object that was null), I fired up my debugger and got confused by what appeared to be null-checks failing to check nulls. Check out this screen shot of the NPE about to be thrown after what appears to be 2 null checks failing to prevent the NPE:

The arrows marked (A) and (B) shows what appear to be null objects passing null checks (in the top pane) even though they’re being reported as null (in the bottom pane). The green line (C) shows the code falling through to that line just before it throws up the NPE.

Of course, value and original aren’t null at all…it’s just that their .toString() methods report them to be null. Here’s the InternetAddress.toString method:

  276       public String toString() {
  277   	if (encodedPersonal == null && personal != null)
  278   	    try {
  279   		encodedPersonal = MimeUtility.encodeWord(personal);
  280   	    } catch (UnsupportedEncodingException ex) { }
  281
  282   	if (encodedPersonal != null)
  283   	    return quotePhrase(encodedPersonal) + " <" + address + ">";
  284   	else if (isGroup() || isSimple())
  285   	    return address;
  286   	else
  287   	    return "<" + address + ">";
  288       }

In my situation, I fell in to the “else if(isGroup() || isSimple())” case, which returns address, which is null, so the .toString() for the whole InternetAddress object is “null.”

I think the toString() method could benefit from another null-check right at line 284, which would mean an InternetAddress object with a null internal address String would display as “<null>”…that’s a more immediate clue that the object itself isn’t null.

You cruise in to the office at 8:45, get your coffee, check the reddits, and ignore that email from your parents asking if their computer picked up a virus because McAfee won’t stop popping up a tooltray icon helpfully informing them that they’re totally vulnerable. Right around 9:15, you get motivated to tackle that 2 point user story for the current iteration.

You head over to the wiki, check out the specs for the requirement, find out what the Trac ticket number is and see if there are any comments with last minute advice or dependencies. None? Good. . . let’s get started!

Oh, huh. . . it’s 9:40. There’s that all-hands meeting at 10 o’clock. I could get started, but I’m not really going to get anything done in 20 minutes really….and that link to the keyboard-cat-three-wolf-t-shirt did look interesting.

The 10 o’clock meeting runs a little long, and then there’s the lunch train, and suddenly it’s the afternoon and you haven’t been in The Zone once.

The Zone

We’ve all been in The Zone – that magical place where time appears to stop and you rock out an insane amount of code in what seems like 10 minutes, but when you look up from your keyboard the sun is down and the cleaning crew is giving you a weird look because you didn’t realize you were trying to sing along to Sigur Ros.

Trying to force yourself into The Zone is like trying to force yourself to see through those stereograms (hint: it’s always a Schooner). And as hard as it is to get in The Zone, it’s annoying easily to get out of The Zone.

There are a lot of recommendations out there to help create “zone-friendly” work places including:

• separate offices
• ambient music
• leaving something intentionally broken the night before to give you that excuse to dive in the next morning
• shift your tasks to the upper right
• Paul Graham’s thoughts on the matter
• etc. etc.

We were wrapping up our all-hands meeting yesterday when the ever-perceptive Dave noted that our weekly meeting schedules were really not all that Zone-Friendly. With a couple of exceptions, we had standing meetings along the following schedule:

And keep in mind, that’s just the standing meetings, so it’s the bare-minimum one would expect. Now let’s add some “procrastination shading” to that calendar to demonstrate the actual standing meeting impact:

If we shuffled some meetings around (especially around the meat of the middle of the week), I think we could end up “finding” 2 or 3 hours a week more conducive to The Zone:

Of course, this is an idealized example, but it’s something we’re thinking about and playing with.

What do you guys out there in development land do? Any recommendations of particular effectiveness?

If you throw an exception about some connection being refused, you’d better damn well put what connection you were attempting to make in the exception message.

What inspired this law?  Thanks for asking.

Check out this snippet in the middle of an 80 line stack dump:

2009-08-25 17:23:42.373::WARN:  Nested in org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'coreAutopatcher' defined in class path resource [config/migrationContext.xml]: Invocation of init method failed; nested exception is com.tacitknowledge.util.migration.MigrationException: Error applying patches:
com.mchange.v2.resourcepool.CannotAcquireResourceException: A ResourcePool could not acquire a resource from its primary factory or source.
at com.mchange.v2.resourcepool.BasicResourcePool.awaitAvailable(BasicResourcePool.java:1319)
at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:557)
at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:477)
at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:525)

“A ResourcePool could not acquire a resource from its primary factory or source”. Awesome. Sooo helpful. /wristsemoragegrowl

Also, a WARN? Seriously? You’re a connection pool. Do you think not connecting to your underlying datasource warrants maybe something as stern as an ERROR? Or, heaven forbid, a FATAL?

I’m sure I could have turned up logging somewhere, but I noticed Spring’s DelegatingDataSource bean standing out from among the stack lines and set a break point on its called method to figure out exactly which of my many connections was unable to be resolved:

There’s the culprit! localhost:5455. You know, whoever the idiot is who runs that localhost server needs to get his act together. I should call the guys from YouTube and have them do a Maury Povich-style video expose on why he can’t keep any of his connections stable.

svn co http://domain.com/svnroot/project/trunk project

That way, when I go to the project directory, I do not have to then go into the trunk directory to get to my files. Saving an extra directory level is not the best benefit though. When I set up my IDE (yes, I use an IDE), I put the IDE files in that one directory and do not have to recreate them for each branch or tag that I might check out. I essentially treat the “trunk/branches/tags” part of the directory as pure metadata, which makes perfect sense to me.

When I switched over to this system, there was one big drawback. I could not easily tell where I am just by looking at my prompt. I had to run svn info | grep URL to see if I was on a branch. So instead of letting my prompt handicap me, I decided to get smart about my prompt. Using bash, my prompt used to look like this:

jeff:/opt/pose/main/report/src/main/java

but now it looks like this (supercharged with Subversion metadata):

jeff:/opt/pose/main/report/src/main/java [SVN: /main/report/trunk]

I’m no bash expert, so I dug around on the web and learned a bit about how PROMPT_COMMAND works. Here is what I have in my .bash_profile now:


function spwd ()
{
stat .svn > /dev/null 2>&1;
if [ "$?" == "0" ]; then
SURL=`svn info | grep URL | perl -pe 's/URL: (.*)/\1/'`;
if [ `echo ${SURL} | grep -E "branches|tags"` ]; then
SVER=`echo ${SURL} | perl -pe 's{.*/(branches|tags)/(.*)}{\1/\2}' | cut -d/ -f1-2`;
SPTH=`echo ${SURL} | perl -pe 's{.*svnroot/(.*)/(branches|tags)/.*}{/\1}'`;
SPWD="${SPTH}/${SVER}";
else
SPWD=`echo ${SURL} | perl -pe 's{.*svnroot/(.*)/trunk(.*)}{/\1/trunk}'`;
fi;
export PS1="\u:\w [SVN: $SPWD]\n$ ";
else
export PS1="\u:\w $ ";
fi
}
export PROMPT_COMMAND=spwd


It may not be the most efficient way to do it, but it sure works well and lets me know in an instant what trunk, branch or tag I happen to be working on at that very moment.