Exception handling
I have been having a converstaion with some of my co workers on usage of Runtime Exceptions e.g.,publicstaticvoid main(String[] args){
try{MyTest mt =new MyTest();
mt.m1();}catch(Exception e){
System.out.println("Exception caught" +"IS true "+"e".equals("e"));
}
}
publicvoid m1()
{
m2();
}
privatevoid m2(){
m3();
}
privatevoid m3(){
thrownew MyrException();//MyException extends RunTimeException
}
Now making MyException a child of RuntimeException has an obvious advantage as shown that you don't have to catch in each and every method or throw it(as you are supposed to do with Checked Exceptions). But what could be the drawbacks while comparing this kind of usage with Checked Exceptions. Or putting it in another way why should one use Checked Exceptions instead of Unhecked ones.
♠
[1839 byte] By [
kilyasa] at [2007-11-26 15:31:04]
Josh Bloch talks quite a bit about exceptions in Effective Java.
Specifically,
Item 40: Use checked exceptions for recoverable conditions and
run-time exceptions for programming errors
Item 41: Avoid unnecessary use of checked exceptions
are most relevant to your situation.
In general, following his advice on this has worked pretty well for me.
> Josh Bloch talks quite a bit about exceptions in
> Effective Java.
>
> Specifically,
> Item 40: Use checked exceptions for recoverable
> conditions and
> run-time exceptions for programming errors
> Item 41: Avoid unnecessary use of checked exceptions
>
> are most relevant to your situation.
>
> In general, following his advice on this has worked
> pretty well for me.
Thats true but on the flip side whole of Hibernate framework is full of Unchecked Exceptions, and as a matter of fact one of my coworkers thought it might be helpful when he was going through the hibernate code.
But apart from "Joshua Bloch said to do this" do we have any semantical reasons or for that matter any reasons at all of why not to do this?
I can say that using exclusively unchecked exceptions is gaining
in popularity. I think the argument there is the flexibility of unchecked
exceptions - you can always choose to handle them.
The counterargument is that sometimes you really do want people
dealing with your exception to be forced to handle it. IOException
is the classic case.
I must confess, I haven't really given this serious thought in quite
a while. Bloch's style has always "felt right" to me, and nobody's
ever given me a conclusive argument that it's wrong, so ...
As mentioned, there seems to be a growing trend to only throw unchecked exceptions. The argument is that you usually aren't able to actually handle the exception anyway, so you just end up wrapping and rethrowing it. We do that here.
I'm no too thrilled with it. I prefer to have the method I'm calling tell me what can go wrong, and to have the compiler force me to handle it. I want to know I've taken care of everything. For our purely inhouse stuff, where all the developers know the convention, and we handle all the exceptions at the top layer anyway, it's not too bad though.
