Learning to Like Exceptions

If you would have told me two years ago that I would being writing Java for my livelihood I would have punched you.

Transitioning from more dynamically typed environments to Java felt like I was being bossed around by javac and I hated it. The most tedious example of this was exception handling. A few projects and library later I’ve learned to love them.

Your Methods Lie

Look at any Android project’s source code you’re going to see source code riddled with null checks like this:

Object thing = mWidget.getThing();

if (thing != null) {

The problem is mWidget.getThing() lied to us. It says it returns Object but it in fact can return nothing or in Java: null1.

Usually the null check exists because at some point calling thing.doSomething() caused a NullPointerException and some poor user experienced a crashing app.

In Java you can’t completely avoid null checks but you can do things to avoid exacerbating the problem.

Don’t be Afraid to Throw

In my efforts to make things easier I find that many times I create a utility method that wraps another “exception happy” method (like working with io).

public class UploadUtil {

  public static Uri uploadImage(Bitmap image) {
    try {
        String filename = BitmapUtil.generateUniqueJpgFilename(filenamePrefix);
        File file = BitmapUtil.saveBitmapAsJpg(photo, Environment.getExternalStoragePublicDirectory(
                Environment.DIRECTORY_PICTURES), filename);

        return Uri.fromFile(file);
    } catch (IOException exception) {
      return null;


Pretty simple to follow: provide a Bitmap get back a Uri and do something with the Uri:

Uri uri = UploadUtil.uploadImage(myBitmap);

Request request = new StreamFileUploadRequest(uri);

But now whenever I use the UploadUtil.uploadImage(Bitmap) method I have to remember to do a null check every time.

If another developer (e.g. my future self) were to use this method they probably won’t know to do a null check unless:

  1. They have access to the source code and read it
  2. The null case is documented
  3. They read the documentation

I thought I was saving myself some effort by handling the exception in one place, but it’s now even worse because instead of a compile time error this has a high chance of not being discovered until a NullPointerException crash.

Nothing is Wrong

The method signature of UploadUtil.uploadImage(Bitmap) says it returns a Uri, so let’s make sure we’re not lying anymore by also returning nothing:

public class UploadUtil {

  public static Uri uploadImage(Bitmap image)
  throws IOException {
    String filename = BitmapUtil.generateUniqueJpgFilename(filenamePrefix);
    File file = BitmapUtil.saveBitmapAsJpg(photo, Environment.getExternalStoragePublicDirectory(
            Environment.DIRECTORY_PICTURES), filename);

    return Uri.fromFile(file);


That’s easy, just throw the exception. Now the user of uploadImage(Bitmap) will have an explicit code path for handling this:

try {
  Uri uri = UploadUtil.uploadImage(myBitmap);
  Request request = new StreamFileUploadRequest(uri);
} catch (IOException exception) {
  Log.e(TAG, "Failed to upload", e);

Another benefit is the compiler will now point out all the places you should have been checking for null.

Be Nice to Others

I used to hate using methods that threw exceptions because of the try/catch dance but I have learned that a thrown Exception is another developer looking out for me.

I have some general guidelines for myself now concerning exceptions:

  1. Instead of returning null throw an Exception if it makes sense.
  2. Wait to catch exceptions at the highest level possible. Ideally when the software is directly interacting with the user.

Exceptions can feel heavy handed and don’t make sense in every case so I’m not dogmatic about these guidelines. If you’re doing Android development using Android Studio then take a look at Nullable annotations.

  1. One exciting thing about Swift is that it solves this problem with optionals.↪︎

Android Debugging with JDB and TextMate

For android development I do my best to avoid Eclipse by using TextMate and the command line. The biggest missing piece with this setup was an easy way to get a debugger up and running. A quick trip to Google landed me on Command Line Android Development: Debugging which outlines how to get jdb attached to a running Android app instance.

I quickly grew tired of typing all of the breakpoints out and invoking a handful of commands, so I hacked together a TextMate bundle I named Android Debug to automate the process.

I have never found a use for TextMate’s bookmarking feature so it seemed like a great place to identify breakpoints. When you invoke the debugging command from TextMate it will find all of the bookmarked lines in the *.java files in your src folder and dump them into a .jdbrc file.


To figure out which app to launch I parse the AndroidManifest.xml file for the package id and main Activity then launch the app in Waiting For Debugger mode.


Once the app is up and waiting a jdb instance is launched and reads the breakpoints in from the .jdbrc file. After getting familiar with all the jdb commands I feel pretty comfortable debugging this way.


Now that I finally have a quick way to debug I can go easy on adb logcat. I’m going to try to automate more parts of my Android development workflow in this bundle. There’s probably some good stuff to steal from the abandoned Android TextMate Bundle.

The only remaining pain point for me in this whole setup is ant. I’d really love it if someone could show me how to get ant debug to compile faster. Currently changing a single *.java file requires 30 seconds to get an apk compiled. It looks like dx is taking a long time to merge all of the pre-dexed libraries the WordPress for Android project is using.

You are not your home directory.

You are not the contents of your source repository.

You are not your farking editor.

You are the all-singing, all-dancing self-replicating code of the universe.

And you are shutting down, one day at a time.

– Comment by reddit user grout_nasa

Lane’s Principle

I was in Chicago last week and the hotel we stayed in was using a new-fangled (to me) keycard. It was a bit strange at first when I got to the door and there was no slot to put my key in. After a few seconds of confusion I realized I only needed to tap the card against the circular pad below the handle and the lock would open.

A few days later, on my way back to my room, a girl stopped me and said her card didn’t work and asked me if I knew how to open the door. I smiled, took the key card she held out to me, slapped it against the handle and opened the door.

I am the Fonz of RFID.

Are you responsive?

My work has had me focused on making websites more responsive. Part of taking a non-responsive design and back-porting some media queries into the CSS is identifying where the breakpoints for a particular design exist.

To aid in identifying where these breakpoints are I built a page with an iframe in it that would tell me how wide it is at any given time. More features were added and eventually we had a useful little tool. So here it is for your pleasure, the elegantly named:


One particularly useful features is the bookmarklet. Drag that thing to your browser’s bookmark bar and then click it when you want to load up whatever page you happen to be looking at.

If you’d like to check out the source code it’s on Github. It’s mostly client side Javascript but with a little Node.js and CoffeeScript to help determine the X-FRAME-OPTIONS header for the site you are loading.

With Our Powers Combined

My friend and colleague, Dan, posted a picture of his officemates.

Here’s the GMT-8 team1 which calls my office home:

  1. Team members starting in the bottom left-hand corner and going clockwise: Apple iPad 2, HP TouchPad (dual boots to Android Honeycomb), BlackBerry PlayBook, Apple iPhone 3GS, Apple iPhone 4S, HTC Something-Or-Other running Android Gingerbread (i think).

Source Control

If a piece of software claims to be able to manage my source code, I want it to manage all of my source code. Let me describe a tool that I use daily for my job whose purpose is to manage source code.

The Tool

This tool is quite simple to use. It’s been around for a while now. It has a straight forward interface and a very easy model of use to understand. I checkout code. I update code. I change code. I update code. I commit code. Pretty dead easy. Maybe a conflict happens but not really usually a big deal.


Sometimes I need to share some of these changes with a collaborator so I use The Tool to make a patch file. I then email/upload/transfer it in some way to my collaborator who — if her code is in the same working state and she knows how to use a tool to apply my patch file to her working copy — she can then apply the changes that are represented in my patch file. Meanwhile, if I make any changes to my working copy my patch may no longer even apply to my own working copy. At this point it could be useful to note what revision my working copy was at when I made the patch, you know, just for sanity’s sake.

Let me reiterate what just happened there. If I want to share some changes that I have made to my source code, I have to use tools other than The Tool (the one responsible for source control). Does that strike anyone else as a little odd? I need to use a tool other than my source control tool to manage my source code.

The patch file that I make has no context attached to it. It knows not which repository it came from nor the state of the repository when it was created. Very quickly the repository is going to change because there are fifty (maybe even more people) committing to this repository all the time.


Sometimes I get an idea — or even less — an inkling of an idea. I want to test it out in my own little sandbox and experiment with it and see if it can go anywhere. This idea consists mostly of new files but it also requires me to modify some existing ones. Time has passed and the idea is somewhat working but I need to get to something else more pressing. Ok, so what do I do with this experiment? I certainly don’t want to lose it because even though it’s not fully baked, there is some value in it.

Guess what? You’re screwed. You can create a patch and save it, but inevitably the files you modified will be changed. Maybe you make a branch1, but no, branches are for important things not your little experiments. Imagine how messy the branches folder would be if everyone used it to dump their little experiments.

Identifying the Problem

I started explaining my woes to one of my coworkers. I try my best to be diplomatic because I am not one to get involved with flame wars. The problem was identified and alas the problem is not The Tool. Apparently it’s my workflow. So perhaps I’m The Tool.

Did I mention how I love Git?

  1. Yes, the “b” word. Please excuse my language.