~pperalta

I saw this article in the Orlando Sentinel, and chuckled at some of the suggestions:

• Orlando: Overdeveloped and growing
• Orlando: Where motorists and imagination meet
• Cleveland, without the glitter
• R skools werks good
• Home of the $7-an-hour employees
• We killed a charming town for you, so get your butt down here and have some fun!
• Big city growth, small town minds
• Gone to the dogs, led by a mouse
• Dyer Straits
• Orlando: The mayor’s your Buddy, and everyone else is your friend.

When I was a senior in college, I wrote a Java front end for controlling X10 devices. In those days, libraries for serial port access did not exist for Java, so I used JNI to call a serial library written in C. When presenting this project to faculty and classmates, one of my presentation points was that checked exceptions were a good thing. This forced the programmer to handle operations that could go wrong instead of ignoring them. In fact, during my demo, a catch block that I had coded to handle IO problems displayed an error dialog. The checked exception forced me to handle that error even though I had never seen it before! This occurred because the demo was being held in the CS lab with lots of other machines on the power grid, whereas all of my previous testing was done at home, where there was much less interference on the line.

Lately I have seen a few blog entries discussing the checked vs. unchecked debate. The first place I can remember reading about this debate was in Expert One-on-One J2EE Design and Development a few years ago. In this book, Rod Johnson advocates the use of unchecked exceptions as the norm and checked exceptions in edge cases instead of the other way around.

Up until that point, I was still a checked exception fan, although I had some misgivings. I had two major pain points with checked exceptions:

• If a method throws a checked exception, any interface methods that it implements must also declare the exception. Often, this exception has nothing to do with the interface.
• What do you do with a checked exception if it can’t be handled where it is being thrown? If you declare that the method throws that exception, that change may have a ripple effect throughout the code base. Before JDK 1.4, wrapping an exception with another one meant loosing the stack trace unless you implemented your own exception type.

After dealing with the pain of many checked exceptions that I could do nothing about (and the boiler plate try/catch blocks that go with them), I am firmly in the unchecked-exceptions-as-normal camp. This is especially true in server side programming, where a SQLException that is nested deep in a DAO usually can’t be reasonably handled and thus has to make its way to the UI to let the user know that something went wrong. I think the reason why checked exceptions worked so well in my college project is that the UI was a thin layer over the JNI library. When working at the UI level (especially in a desktop application), it is helpful to know what can go wrong because it is easy to display an error message of some sort to handle the exception. However, most of the time applications are making deep calls into APIs which call other APIs. For non trivial applications, unchecked exceptions are the way to go.

For further reading on this topic, see this article by Bruce Eckel.

I just tried out Ruby on Rails for the first time after reading the article “Railing on AJAX” in the November 2005 edition of Software Development. I first saw RoR in action at No Fluff Just Stuff demoed by Dave Thomas. This is a framework that strictly adheres to the DRY (Don’t Repeat Yourself) principle, which means that changes in configuration are only required in one area instead of having rippling effects throughout the application. It also relies heavily on convention instead of configuration, so once you’re familiar with the setup it is quick and easy to add functionality. Scripts are provided for generating web applications, controllers within those applications, and more. It also comes with an ORM tool known as “Active Record” which is supposed to be very nice for simple CRUD operations.

This article also mentions the AJAX support provided by RoR, and it gives a simple example of how to use it. In the example, no JavaScript coding is required…the application comes with JavaScript libraries called from Ruby for performing the AJAX calls.

Ruby, RoR and AJAX have received quite a bit of press coverage lately. It will be interesting to see how they affect the industry in the coming months and years.