Jug-Ka Summer Stammtisch

Since we haven't had a Stammtisch of the Java Users Group Karlsruhe for a while, I thought it's time to get together again.

We are gonna meet on Wednesday, July 15th - 20:00, at a nice pub called Litfass, near Marktplatz. For further information you can send an email to our Google Group or join us on Xing.

When Unchecked Exceptions Go Wrong

In the application I'm developing right now, we found a bug right before going live. A colleague of mine forgot to catch an unchecked Exception in a loop, which led the loop to exit, before iterating over each element. Bugs like this are so subtle and hard to track, that's why I think it was kind of my fault for not using a checked instead of an unchecked Exception.

// must work all jobs
private void workAllJobs() {
  for(MyJob job : allJobs) {
    job.work(); // throws RuntimeException
  }
}

Let me be clear, I don't want to engage into the checked vs. unchecked Exception war. I made my point clear a couple of times, however I simply think I need to revise my position.

I used to think forcing a client of an API to catch an Exception was evil! That's why I usually design custom Exceptions to inherit from RuntimeException and declare each and every case carefully in the javadocs of my API methods. I simply followed the expert's advice:

Always declare checked exceptions individually, and document precisely the condition under which each one is thrown using the Javadoc @throws tag. .... While the language does not require programmers to declare unchecked exceptions that a method is capable of throwing, it is wise to document them as carefully as the checked Exceptions.

Unfortunately, the expert's advice didn't work in my co-worker's case. Should I say in most cases? He is with the sad majority of developers, that don't ready javadocs - not even on public API methods. Maybe I should have listened to people telling me this:

I kind of disagree with your example; documenting everything in every tiny detail may be a requirement for widely used public APIs (like the JDK), but IMHO a more relaxed approach is useful for the rest of us. Like "configuration by exception" is considered a good idea, there should also be "documentation by exception". That is, don't document every tiny detail but instead follow some higher level conventions. Many people do that intuitively, but unfortunately forget to document those conventions.

Like Matthias, my co-worker argued, that he thinks conventions should define what happens if e.g. you pass null to a method or which Exceptions are being thrown from an API method. I do agree, conventions are a great tool to define this kind of behavior. The problem with conventions are: How do you get the whole team to agree on certain conventions and more important - how do you manage those convetions?

Getting a team of strongly opinionated individuals to even agree on minor details, e.g. how to name interfaces, is almost impossible. Believe me, I have been there! After more than a year, we still can't agree on wether to use Eclipse's notation of IService or my preference - simply Service. I cannot imagine how hard it will be to agree on really important topics like passing null to methods and wether to throw IllegalArgumentException or NullPointerException in that case.

The second issue with conventions is how to manage them. Who is responsible to maintain those agreements? Do you put those conventions on a wiki page, which nobody updates and nobody reads anyways? I argue, that for us developers code and eventually the IDE is where we live, thus I think that's the place those conventions should live as well. Code is the common single point of truth for us and hence javadocs are in my opinion the best way to document any code related conventions.

I guess you can see where this is going. It's a trade-off, as always in software development. However, it's a trade-off with a catch. I think it's simply not enough to "just have conventions", they need to be documented and managed in the code and my weapon of choice for doing that is javadocs.

Java Forum Stuttgart

Yesterday, I was attending the 12. Java Forum Stuttgart and compared to the last time I went, which was in 2005, the event has really fledged.

The quality of the sessions was good and the hallway was filled with familiar faces. The theme of the conference for me, was JPA and O/R mappers. There were a couple of really great talks about it and it seems like there's a lot of going on in that area at the moment.

I'm definitely gone be there again next year and I would love for the conference to be extended to a 2-3 days event.

Wrapping-up Jazoon09

I was attending Jazoon09 in Zurich, Switzerland last week. As with springOne 2009, I wasn't really satisfied with this content of the conference.

The problem was, that there were only a few really good speakers and thus only a couple of great talks. The keynotes were average, only Adrian Colyer's presentation on the last day was standing out. Even James Gosling's presentation or Danny Cowards talk were both not that exciting.

However, instead of telling you what sucked, I rather want to highlight, that the organization of the conference was great! The food was really good! There was an vegetarian alternative every day and the coffee was delicious. Jazoon took place in a movie theater, just like Devoxx, thus it was easy to get there by train and the seats were nice and comfy. Kudos to the organizers.

There were a couple of great talks I want to highlight: Neal Ford's "Smithying in the 21st Century" as well as Ed Burns' "Secrets of the Rockstar Programmers" were really awesome and I can only commend listening to them, in case they come up on the schedule of another conference.

I'm not too sure if I'll come back to Jazoon next year, although I think it could be a really cool conference and a great alternative to Devoxx, which takes place in Antwerp.