Rafael Naufal's blog

Nice post from Bruce Eckel about whether Java needs or not checked exceptions. I have to admit, I changed a lot my thougths about using checked exceptions in Java code with this post. He explains why it’s better to use unchecked exceptions instead of checked ones with some good arguments, like the possibility to swallow the exception inside an empty catch block and loose the stack trace information. The programmer is tempted to swallow the exception because he’s forced to catch it and write reams of code around the exception. Bruce also states, emphasizing the use of unchecked exceptions:

“If I want to catch the exception, I can, but I’m not tempted to swallow it just to avoid writing reams of code. If I don’t’ want to write around the exceptions, I ignore them, and if one comes up it gets reported to me during debugging, and I can decide how to handle it then. I still deal with the exception, but I’m not forced to write a bunch of code about exceptions all the time.”

I think there’s a tendency to apply checked exceptions because people are used to static type checking, people are afraid to catch errors at runtime, static type programming languages forces this. People from Python, Ruby are used to the unchecked approach, because those languages are dynamically typed, so, there’s no pain :-). Now I prefer to use unchecked exceptions rather than checked ones because I agree with Bruce’s arguments and I’m moving my thoughts forward to dynamically typed languages. And you, what do you think about using checked / unchecked exceptions? Do you have a different opinion?

Tags: java

Sometimes I’ve seen some Java code intended to indicate the absence of parameters, that is, code validating null parameters (every public method must have a test to check against null parameter), verifying if a certain range is respected (like date, number ranges) and other kinds of contextual validation before calling the objects’ public methods. Some validation code (written in Java) is shown below:

At class Player:

public void pickUp (Item item)
{
   assert(item != null): "item cannot be null";
   // some code here
}

The above code uses Assertions, introduced in JDK1.4, to validate the item parameter. If item is null, an AssertionError will be thrown with the message “item cannot be null”.

public void drop (Item item)
{
   if(item == null) {
      throw new IllegalArgumentException(“item cannot be null”);
   }
   // some code here
}

This above one uses an IllegalArgumentException, which is a RuntimeException, to report a null item.

public boolean addToInventory (Item item)
{
   if(item == null) {
      return false;
   }
   // some code here
}

And this above Java code snippet returns false if an item is null.

or, maybe, applying the NullObject design pattern:

class NullItem implements Item
{
}

and at Player it becomes:

public void drop (Item item)
{
   // some code here
}

The last avoids a lot of tests to see if the parameter is null, replacing the tests with an object that provides the appropriate null behavior (“do nothing” behavior).
The question is: which do you think is the best way to indicate the absence of such an object? Which do you use often? Tell me if you use another approach to report this.

Tags: java

CRN is announcing that Sun is set to put JavaMe and J2SE under the GPL license. Last months Sun commented about putting its Java plataform under a public license, but they were deciding which license to put Java into. Now the preferred choice is GPL. I think it’s to promote and increase Sun’s reputation in the open-source community. However, as the new said, a GPL license would require those developers making changes to the core Java platform to freely release their code. What do you think about this? Has Sun made the right choice? And what about Apache’s license?

Tags: java