You might already know how frustrating it is to add a try catch block on those java.io api and date parsing API. The reality is, when such exceptions occur, something terrible most probably happened and you don’t want your application to proceed normally. Ofcourse, you can have a try catch block and convert checked exceptions into a Runtime Exception, just like frameworks like Spring and Seam do. But still, something fundamentally needs to change. The compiler — should stop telling you what “it thinks” is important for you, and leave the decision to the developer with a language feature to explicitly ignore.
Consider this example of a simple date parsing api, where I have to manually convert to a runtime exc
public SimpleDateFormat getDate() {
try {
simpleDateFormat = new SimpleDateFormat(" MM/dd/yyyy");
return simpleDateFormat.parse(date);
}
catch(ParseException e) {
e.printStackTrace();
throw new RuntimeException("Cannot Parse date, format must be MM/dd/yyyy");
}
}
can now be,
@IgnoreException(name="ParseException", message="Cannot Parse date, format must be MM/dd/yyy")
public SimpleDateFormat getDate() {
simpleDateFormat = new SimpleDateFormat(" MM/dd/yyyy");
return simpleDateFormat.parse(date);
}
For cases where 3,4 checked exceptions are thrown, it becomes even messy trying to figure out whether to have a common catch block or throw them all to the top (which forces every API above, to have the same “exception” signature)
Consider this example of a JavaBean API where I try to work around property descriptors and Java Class api
protected T processLine(List<string> line) throws IllegalAccessException,
InvocationTargetException, InstantiationException, IntrospectionException {
T bean = (T) mappedBean.getClass().newInstance();
for (int pos = 0; pos < line.size(); pos++) {
String value = line.get(pos);
PropertyDescriptor propDescriptor = findDescriptor(pos);
if (propDescriptor != null) {
Object obj = convertValue(value, propDescriptor);
propDescriptor.getWriteMethod().invoke(bean, new Object[] { obj });
}
}
return bean;
}
We could have a similar annotation, like @IgnoreExceptions { } annotation with multiple IgnoreException lines.
Isn’t that more graceful and more power to the developer? I bet, YES!
Post a Comment