Personal Workflow Blog

To content | To menu | To search

java

Some random thoughts collected meanwhile working on an Enterprise-grade J2EE stack.

Entries feed

Saturday, 20 February 2010

Free Exception lunch : Use unchecked exceptions, but still announce which ones you might throw.

In a previous article I choosed my side : Unchecked Exceptions are much simpler to use.

But, on the other side of this great division, there is a very valid point : You usually declare checked exceptions. Sure it's possible to only declare to throw Exception, but that would defeat the whole purpose of using checked exceptions.

The nicest thing is that you can also have a custom exception hierarchy, but based on RuntimeException instead of a plain Exception. This way it's like in C++. Everything might be thrown, and you don't need to handle them.

Declaring them, on the other side, is very interesting because you are documenting your interface for almost free.

So, use unchecked exceptions to free yourself of the checked catch-slavery, but still declare the custom ones you might throw.

Monday, 7 September 2009

Overloading a method is hard : a common pitfall

As I said in my equality article, overloading in Java[1] is resolved by the static type of the argument, not the run-time type.

It's a generic problem of most compiled OO languages since usually overloading resolution happens at compile-time and not at runtime.

Now, that militates for the well known idiom :

Never overload a method with one that has the same number of parameters.

Actually, it should be enough to overload a method with one that accept parameters that are not inheritance-related : String and Number would be OK, but MyClass and Object would not.

Notes

[1] It's not really a Java-ism, it's the same in other languages, such as C++ .

Wednesday, 15 July 2009

Checked or Unchecked Exceptions for Legacy Code ?

This question can almost trigger a religious war. On Internet no fixed consensus on the matter seems to exists. But most of the articles there have usually something in common : they are always mostly applicable when you start a new application.

Is the situation the same when you have a certain amount of existing code to maintain ?

Continue reading...

Monday, 1 June 2009

Equality in Java is a Hot Topic, but a Hazardous one.

It seems that comparing two objects isn't as a simple task to do as it seems at first.

My concept for smart comparison still holds, but is completed perfectly with the How to Write an Equality Method in Java article posted on Artima soon after mine[1].

2 main points that you have to be careful to (Others are also detailed in this article) :

  • hasCode() has to be redefined usually since otherwise the equality contract on Object.hascode() would be broken.
  • the equals() has to take an Object as parameter since overloading in Java is resolved by the compile-time type of the argument, not the run-time type.

I just got bitten by the second one, but not much (yet) since I mostly rely on compile-time overloading. My purpose here was only to compare objects either to constants or to simple variables. But in the generalization I would certainly have overlooked this and be bitten much more deeply.

Notes

[1] But as much as I wished it to be, it is not related :-)

Tuesday, 26 May 2009

Compare Efficiently in Java : Embrace Smart Comparison

In Java, comparing things can be quite tricky. Comparing them with a simple == only compares the references, and for example 2 strings could be the same without being the same object. You have to compare them with the equals() method. Now the infamous NullPointerException (NPE) shows its ugly head when the first object to compare is null.

Continue reading...

- page 1 of 3