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.

C, C++, Java, Haskell?

I’m excited and distressed with my OpenGL adventure. At the same time that learning OpenGL makes me pleased, it also makes me irritated: I’ve dedicated much time learning Haskell and got involved in a way to really like the language and the community. But, doing something in OpenGL was very hard and lonely. There are very few content about it and the majority are already obsolete.

I did put Haskell at the corner for some time and refreshed my C knowledge to learn modern OpenGL, with shaders and buffer objects. The reason was simple: I didn’t manage to do anything in Haskell that actually worked and had no clue if the problem was with my code or with the libraries I was using.

Well, to make a moving camera in a 3D world was difficult, even in C. But, I’ve found lots of good stuff on the internet to help me do it. Using all this help, I’ve managed to make it work.

I’ve decided to get back to Haskell to apply this knowledge I just got.

Oh dear! To make everything fit together and with the right types made me sweat some t-shirts. If I wasn’t so stubborn, I wouldn’t do it. I’ve switched OpenGL by OpenGLRaw because the OpenGL package has no binding for “glUniformMatrix*”; also switched GLFW by GLFW-b because the first one has a dependency with OpenGL package.

I read a post at InfoQ asking if the C language was still suitable. Made me think on lots of stuff, including on to abandon Haskell and get back to pointers, manual memory management, hairy strings, …

Perhaps it’s because I’m new to this world, but I feel kind of unproductive while programming in Haskell. My impression is that, unless it’s something very well consolidated and used by lots of community members, a lot of time will be spent going after libraries that usually are just a binding for one written in C. When that’s not the case, just to take a breath of the library’s API, I need to read some papers trying to remember all the magic about Functors and Monads (I think I’ll need some books to really understand Arrows!).

To understand pointers and memory management in C was difficult too. But back then I was a young boy at the world of programming, my knowledge was very limited, it was based a lot on punching the code until it did what I wanted. I can’t accept this anymore, I need to understand what I’m doing.

I remember I had good reasons to change C for Java. After a while using Java, I started to see the cons of the language too. My undergraduate work was dedicated to point the reasons of this change and the promising future of languages like Haskell.

I believe that this negative feeling happens with every language that you spend some time learning. The propaganda and the first steps are wonderful. You imagine a new world where everyone is rich and can enjoy all the beauties of life. With time, you realize that it’s not like that: every decision the language has made means positive and negative points to us, programmers. I’ve experienced this with C, Python, Java and now with Haskell.

Java has chosen the O.O. way: even if it’s a static function or a global variable, the class wrap will be there. Haskell picked the pure functional way: even I/O operations are wrapped within a monad.

This is not bad at all. The use of monads to model sequential computation was a great discovery that led to a lot of other solutions. All the choices made brings with them some pros and some cons. (Just take caution with the extremism [e.g. Singleton].)

I’m distressed because I don’t know what to pick:

  • C looks flexible but with complexities I’m not wishing to have. C11 may have fixed some (e.g. ), but GCC has no support for it yet;
  • I feel productive in Java but the inherent overhead and the need of a JVM makes me angry;
  • C++ I don’t know well, but I think I’d prefer going into C than this one. Java has shown me good reasons to say no to O.O. But, even GCC is using C++, maybe I’m missing something. The libraries for C++ looks great (e.g. GLM, Boost);
  • Haskell is my favorite, but it’s starting to bother me little, this feeling of being stuck, without delivering anything, makes me tense. Maybe I need to give some more time for it to really kick in. I don’t know if this commitment will worth it or I could make a better use of it enhancing my skills in another language.

The performance difference between C and Haskell don’t bother me much, because I’m not going to do micro-optimizations so early.

The ultimate answer is something like: it depends on your project, choose the right language for the right project. Well, I have no project at all, but I want to get deeper into game development.

What should I do?