Git Stash

After a great talk on Git at the Java User Group Karlsruhe and a couple of other experiences, I started to really dig the Distributed Source Control Management (DSCM) notion and its advantages. A neat and quite helpful feature of Git is stashing.

The Git manual has as an exceptionally helpful description of stashing. They call it "Temporarily setting aside work in progress".

While you are in the middle of working on something complicated, you find an unrelated but obvious and trivial bug. You would like to fix it before continuing. You can use git-stash(1) to save the current state of your work, and after fixing the bug (or, optionally after doing so on a different branch and then coming back), unstash the work-in-progress changes.

$ git stash save "work in progress for foo feature"

This command will save your changes away to the stash, and reset your working tree and the index to match the tip of your current branch. Then you can make your fix as usual.

... edit and test ...
$ git commit -a -m "blorpl: typofix"


After that, you can go back to what you were working on with git stash pop:

$ git stash pop

Git's stashing feature saved me quite some trouble a couple of days ago, while working on a side project. I developed a feature on branch "B" and had quite a big change-set, while someone found a bug on the stable branch, let's call it "A".

Coming from SVN, I thought I had to check-in my changes in order to switch to Branch "A" and fix the bug. That's quite ugly, because it screws with your history of commits and even might break your builds. I know that there are other possibilities with SVN, like copying your changed files or creating a patch file. However, to me those all look like workarounds rather than solutions.

So I simply stashed my changes from branch "B" and got a clean branch with HEAD. I switched to branch "A" and was able to fix and commit the bug. After switching to branch "B" again, I simply poped the changes from the stash, as if I had never stopped working on the feature.

After working with Git for some time, I would really recommend people to switch to a DSCM. I'm not alone with this. SpringSource's DM server team migrated their repositories to Git a couple of weeks ago and they didn't hear any complaints from the community. No matter if you choose Git or Mercurial, the advantages of a DSCM really outweigh the initial costs of getting started.

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.