Recently I had to write a Generic Mock DAO object that simulates behavior that of Hibernate. That is if you call makePersistent(T entity), then if the Id field of the entity hasn't been set the method should set it otherwise check if the entity already includes the id and update the entity stored in the mock "data storage". Ok, so I had some reflection code as follows:

try {
			Method getIdMethod = entity.getClass().getMethod("getId",
					new Class[] {});
 
...
	Method setIdMethod = entity.getClass().getMethod(
						"setId", new Class[] { typeOfId });
 
	} catch (SecurityException e) {
		} catch (NoSuchMethodException e) {
		} catch (IllegalArgumentException e) {
		} catch (IllegalAccessException e) {
		} catch (InvocationTargetException e) {
		}

Now what happens is my coworker used the Generic Mock DAO but the id property of his Entity had a private setter, now when he called the makePersistent method a NoSuchMethodException was swallowed leaving the coworker puzzled for short time why is the mock dao not working. Naturally I changed getMethod to getDeclaredMethod and added setAccessible(true); (to enable access to private properties) and it worked. More importantly I changed error handling code to as follows:

} catch (SecurityException e) {
			throw new RuntimeException(e);
		} catch (NoSuchMethodException e) {
			throw new RuntimeException(e);
		} catch (IllegalArgumentException e) {
			throw new RuntimeException(e);
		} catch (IllegalAccessException e) {
			throw new RuntimeException(e);
		} catch (InvocationTargetException e) {
			throw new RuntimeException(e);
		}
 

now should somebody want to use the mock dao with an Entity without the id property a RuntimeException will be thrown meaning, he will know very soon where is the problem. Having an entity without the id property is a programmers error therefore it is true that in production the NoErrorException will never be thrown by the code but it sure doesn't hurt to throw a RuntimeException to signify a programmers error.

Moral of the story: even if you are sure that some errors will not be thrown consider throwing them as RuntimeExcpetions it will pinpoint the problem in an instant.

                try
                {
                    b = new BufferedReader(
                        new InputStreamReader(myInputStream,"iso-8859-1"), 1000);
                }
                catch (UnsupportedEncodingException uee)
                {
                    // can't happen - jvm spec ensures iso-8859-1 supported
                    throw new AssertionError(uee);
                }

catch (DataConfigurationException dce) {
    // Dave assures me this can't happen in this case
    throw new AssertionError(dce);
}