Software Steeplechase

I use Eclipse as my Java IDE and when I invoke a method that throws an exception, Eclipse provides a nice compiler warning indicating that I must enclose the method in a try/catch block. The IDE (Java compiler) only warns me about some exception types and not others. For instance, if I were to invoke List.add(int, obj), it may cause an ArrayIndexOutOfBound exception, but the compiler doesn’t warn me about this. However, if I code File.createNewFile(), I am warned that IOException must be caught.

I understood the difference between checked exceptions VS unchecked exceptions, but didn’t know how the compiler differentiated. As it turns out, the short answer is very simple.

Unchecked Exceptions implement java.lang.RuntimeException

…while Checked Exceptions do not. (They directly extend java.lang.Exception or some subclass thereof).

Here are some great articles regarding exception handling.

Designing with exceptions, Java World documents how the existence of exceptions should be closely related to the role of the Class and how people are expected to use it.

The exceptions debate. To check, or not to check?, IBM developerWorks briefly covers checked vs unchecked exceptions and quickly gets into good criticisms of each pattern.

Exception debate among industry “names”, Old Joel on Software Forum post contains the views by people who are considered industry experts.

As far as the debate goes, there are very smart people who completely disagree whether exceptions should be declared as unchecked (runtime) or checked (compile time). I have yet to make up my mind.

I ran into a problem while working with a procedure that maps POJO properties from one Java object to another. The code assumes that each object’s ‘get’ method returns a direct reference to some internal property. Therefore, the code doesn’t bother to call the POJO’s ’set’ method after it manipulates the retrieved object.

Example 1:

public class pojo1{

  private List list1;

  private List getList1(){
    return list1;
  }

  private void setList1(List list){
    list1 = list;
  }
}

The procedure would call pojo1.getList1(), manipulate objects in the List, assume that the state of pojo1 has been updated, therefore not bother to call the pojo1.setList1(List) method.

This is blatantly anti-OO, as the code is making assumptions about the internal implementation of the object.

This code was working fine, until I sent it a JavaBean whose implementation details did not correspond 1 to 1 to the available ‘get’ methods.

Example 2:

public class pojo2{

  private List list1;

  private List getList1(){
    List subList = new ArrayList();
    //Iterate over list1
      //build subList with only certain elements of list 1
    //return subList
  }

  private List getList2(){
    List subList = new ArrayList();
    //Iterate over list1
      //build subList with only certain elements of list 2
    //return subList
  }
}

The code in example 2 will fail, because the procedure manipulating the data would not be working on the actual data abstracted by the JavaBean.

When working with JavaBeans it is safer to assume that values are being passed by value and to explicitly call ’set’ methods if that data needs to be changed.

A better idea is to avoid using so many getter/setter methods altogether as advanced in this JavaWorld Article. It makes some fine points about the dangers that procedural programmers make with their usage of JavaBeans, but I think it leans a little bit too heavily towards the ‘purist’ camp. However it is accurate in telling how many people know the bare minimum when it comes to such an important aspect of Java programming.