DevDisasters

The Great Conversion Function

Long hours finally took their toll on Adam's health, so Gerry picked up the slack in his own peculiar way -- introducing some slick do-it-all function.

• By Mark Bowytz
• 06/04/2015

Getting a follow-up e-mail from Gerry at 2 a.m. is not all that uncommon. It's not that he's in another time zone, it's just that he never disconnects. To put it another way, when it comes to handling application issues, a pit bull is his spirit animal.

Managers and users love it. Everybody on his team loves it, too…well, most of the time they do.

Case in point: One of Gerry's teammates, Adam, was working on a lengthy, complex project to support the recent acquisition of a new business unit. Deadlines were tight and as a side effect of long hours and little sleep, Adam's health began to suffer. Ultimately, it caught up with him and Adam had to call in sick for a day.

While he was recovering, a bug report came in. Nothing major -- it was the Boolean logic behind the Yes/No radio button on a Web submission form. No doubt it was an easy fix. Being the eager beaver and ever helpful guy, Gerry pounced on it and alerted the troops with the following e-mail:

"From: Gerry.G
To: *QA-Team-US
CC: *Business-DevTeam
Subject: RE: Issue 2408-01 Customer Inquiry Portal

--------------

Team,
Thank you for bringing this to our attention. 
I'm sorry for the inconvenience - I will triage this issue and 
address it while Adam is out.

Regards,
Gerry

A few hours later, Gerry followed up with another e-mail:

From: Gerry.G
To: *QA-Team-US
CC: *Business-DevTeam
Subject: RE: Issue 2408-01 Customer Inquiry Portal

--------------

Team,
After reviewing the issue, this condition has been resolved and has passed 
the attached testing scenarios. The fix that I provided will ensure that this 
condition does not recur in the future. I have submitted the necessary 
workflow authorizations for promotion from QA to Test.

Regards,
Gerry

Grateful thanks and a shower of kudos were sent in return. The bug in the radio button logic was fixed and Adam didn't even need to be disturbed.

A few days later, Adam made it back into the office, feeling much more like his old self, and, after catching up on e-mails, he noticed Gerry's change that went in during his absence.

He started to pen an e-mail thanking Gerry for his help, but figured that, at the very least, it would be wise to at least understand the changes that he had put in first.

Without much effort, Adam tracked down the code change that fixed the bug: a simple, one-line tweak that correctly assigned the radio button setting. (Lesson learned here is, don't try to code with a fever.) However, that wasn't all. Now, after fetching the radio button value from the database, every result was converted.

This wasn't an attempt at simple bulletproofing. This was more like armor plating:

public Object convert(Object object)
  throws ConverterException
{
  if (object != null)
  {
    Class<?> objectClass = object.getClass();

    if (objectClass == String.class)
    {
      String s = ((String) object).trim();

      if (s.equalsIgnoreCase("true") ||
          s.equalsIgnoreCase("yes"))
      {
        return Boolean.TRUE;
      }
      else if (s.equalsIgnoreCase("false") ||
               s.equalsIgnoreCase("no"))
      {
        return Boolean.FALSE;
      }
      else
      {
        throw new ConverterException(
          "Cannot parse input.");
      }
    }
    else if (objectClass == Boolean.class)
    {
      return object.toString();
    }
    else
    {
      throw new IllegalConversionException(
        "Conversion undefined for input: ",
        objectClass);
    }
  }

  return null;
}

As far as do-it-all functions go, Gerry's work was pretty impressive.

The code works in both directions, so it can return "true," "false," Boolean.TRUE, Boolean.FALSE, null or exceptions, depending on the input (Adam's favorite was the silent null).

Also, it does == on classes instead of instanceof. Gerry remembered to save the trimmed string, but not the tolower, instead doing an equalsIgnoreCase.

And, as a bonus, it's in good shape to support file-not-found in the future.

But, was it worth confronting Gerry?

Rather than turn a presumably helpful intention into a possible personnel incident, Adam chose the high road. After all, Gerry had fixed the code while he was out. So, Adam thanked him for the excellent help and at his next opportunity quietly removed the convert function. Perhaps it would leave the code slightly less bulletproof, but definitely easier to maintain.