Code infected with exceptions

I believe that code infected with exceptions is bad. Imagine the following harmless code:

public static Foo newFoo(int bar) {
  switch (bar) {
    case 1: 
      return new FooOne();

    case 2: 
      return new FooTwo();

    default: 
      throw new IllegalArgumentException("invalid bar code: " + bar);
  }
}

You use it in the middle of your business code with ease. The code compiles and everybody is happy:

public static List getAllBazFoo() {
  List result = new ArrayList();
  List allBaz = BazDAO.getAllBaz();
  for (Baz baz : allBaz) {
    int id = baz.getId();
    int bar = baz.getBar();
    Foo foo = Foo.newFoo(bar);
    BazFoo e = new BazFoo(id, foo);
    result.add(e);
  }
  return result;
}

The problem is that the call Foo.newFoo(bar) can throw an IllegalArgumentException and when this happens you will have no clue of which Baz was invalid.

To address this and make the message more useful, we have to remember to add a try/catch in the code:

public static List getAllBazFoo() {
  List result = new ArrayList();
  List allBaz = BazDAO.getAllBaz();
  for (Baz baz : allBaz) {
    int id = baz.getId();
    int bar = baz.getBar();
    Foo foo;
    try {
      foo = Foo.newFoo(bar);
    } catch (IllegalArgumentException e) {
      throw new IllegalArgumentException("invalid baz: " + id, e);
    }
    BazFoo e = new BazFoo(id, foo);
    result.add(e);
  }
  return result;
}

Add multiple layers of abstraction to your application and you’r ready: spaghetti with an exceptional taste. You add an exception at some point and you will have to review the entire stack of abstractions you have to ensure that the exception does no harm to anyone and has a useful message for future maintenance.

Haskell solves much of the need for exceptions using returns that symbolize failures, e.g. Maybe and Either, and the use of Monad eliminates the need to check the results at each step.

However, there are exceptions in Haskell, why? I can not understand the reason for preferring exceptions rather than special results. In which situations is it better to use exceptions? They look like a modern goto to me.

Book: Code Simplicity

I just read the book “Code Simplicity: The Fundamentals of Software“.

The author tries to build up a sciente of software development. There are about 90 pages that discuss important details of this engineering without touching a single line of code.

Among the issues cited by the author, the one that impressed me most was the formula for the cost of a change in software.

This formula, when applied to time, makes it clear that the future value plus the cost of maintenance of a change will have a much higher weight than the immediate cost and value. As time goes by, the effort put into maintaining a feature far outweighs the initial effort to code it. I’ll not go into too much detail, if you are curious: go read the book.

It was a very enjoyable read. I’m sad that I got into this book by chance, no one pointed it to me. I feel that I could have avoided a good amount of frustration that I had as a developer. The author’s ideas seems to fit with all the insights I had developing and maintaining code.

I leave here my statement for all who work in the software field: you need to read this book! Regardless of writing code or not, you will have a much better basis for making decisions that affect your product.

If you’ve read, leave your comments about what you think.