There is always more than one way

This is a follow-up of sorts on my post on checked Exceptions in Java.

The Apocalisp blog has an interesting series (part 1, 2, and 3) on using a functional programming style for your exception handling in Java. The series ends in actually removing Exceptions entirely from the majority of the code, and using the Option monad to handle your output.

It is a sideways re-introduction to some functional programming concepts/constructs like Monads and lazy evaluation.

But be warned, the posts are not for the faint at heart, and you may need to brush up on your functional language skills to get the most out of it.

Cruise Missile Cousin

We have a tool we call the Cruise Missile that tells us how our build is running on each of our projects. We put it together pretty quickly but it does a good job of telling everyone at youDevise how our development is going.

Cruise Missile has lots of relatives, including lava lamps and ambient orbs. Another relative I read about today sounds like fun – a huge TV showing not only build status but the current production version of the product (a live news web site) and news anyone can update. There may be some features there we want to add to our missile!

Checked Exceptions Are Wrong

Please note that this opinion is mine (and others as listed in the articles). This is not an edict that all code at YouDevise should be written without throws clauses. Just some food for thought.

So, it has been a bit mellow on the blog lately. I want to liven it up with a bit of a heated (nerdy) topic. Feel free to debate and discuss this in the comments.

A lot of people smarter than me have commented on whether Checked Exceptions are useful, so I am going to mostly link to their arguments. Do read the linked artickes. They are very insightful.

Here are my favorite points:

Checked exceptions are syntactic salt. The extra try/catch hoops that you have to jump through tend to make code less expressive and noisy.

Checked exceptions are hard to do right.
Often, they are so hard to do right that the Java language designers and other Java pundits cannot agree on any good practices for using them. Heck, people are seriously considering petitioning to remove the from the Java language.

Checked exceptions are a (failed) experiment. Java is the “first” language that used checked exceptions. Languages have been designed since then without checked exceptions. In fact, I cannot name a single major language since Java that has them… (Please correct me if I am wrong on that last point.)

My personal opinion? They rarely make my code more expressive, so the extra syntax and lines of code get in the way. As of late, nearly every Exception that I come across just means that the database threw an exception. These exceptions are almost always not recoverable, except at the highest layers of code, where you report an error status or other message to a user.

Anywho. What are y’all’s thoughts?

Source control woes

One of my Dev Services task this week was to investigate alternative source control systems to replace the aging CVS. Although the original plan was to move to SVN, it was decided to play around with a few distributed source control systems such as Git, Mercurial and Darcs.

The main metric used for the evaluation was how decent is the Eclipse plugin for the given system and as a playground I’ve used the CruiseMissile project straight from our CVS.

Unfortunately my report is pretty quick: none of the plugins are worth it so far. Although they are in constant development, they are still in a crude alpha state which would be risky for us to rely on. File diff and merging are poorly implemented, and some of the basic features we are used to, from the CVS plugin, are not available yet.

Thus, we are moving to SVN, at least for now. Apparently there are better tools for moving from SVN to some of these distributed systems, so that may still be an option in the future.