Exception handling approach for method overriding

[prateek shaw]

Hi All,

I know everyone are aware of this. Overriding is interesting , importance and confusing topic to understand.This feature is to support inheritance and polymorphism(as a high level concept).
And if you think, this narrow down to only one point , you have one method defined super /base class and you want to define same method into your child / inherit class.
Above is just bring my below point.

My doubt is regarding exception in overriding. There are several rule which are below..

1-You can throw any new unchecked exception which is not thrown by base method. I agreed with this point 100%. Advantage
2-You can throw the same exception in your child class. Make sense since this is same thing as parent class.
3-You can throw sub class of exception which is thrown my base method. Make sense.
4-Even you can removed exception , wow really . First it was confusing but later i understood and below is my understanding , what is reason behind this?.

public class JavaExample2{
	
	public void m1() throws Exception{
		
	}
	
}
public class JavaExample extends JavaExample2{
	
	public static void main(String agus[]){
		JavaExample example = new JavaExample();
		example.m1();
	}
	
	public void m1() {
System.out.println("in sub class method");
	}
	
}

I feel this is allow because it may be possible that overriding method does not want to throw any exception. And it is correct too.The next confusion was how does this work.
The main point to observe here is that, "from where you are call this method". In above classes , if i am calling method from sub class. reference

JavaExample example = new JavaExample();
		example.m1();

It will not give any compiler error and work. however if i try to call  same method from super class reference.Then this does not work.

JavaExample.java:7: error: unreported exception Exception; must be caught or declared to be thrown
               example.m1();

And i know why this is not compiling.

public static void main(String agus[]) throws Exception{
		JavaExample2 example = new JavaExample();
		example.m1();
	}

Since base class is throwing checked exception therefore i do not have option i should use try catch or re throw this.
But this is something different than normal. Overriding work in run time therefore it will call the child method because the object is child object.
But this is kind of interesting that why Java did like , Is there any other way to implement this ?
If they can allow us to type cast to class to any interface object even if they do not have any relation each other at compile time.

This is my way of understanding this concept, i will accept your suggestion and your way of understanding. Please do share your knowledge.

Thanks,

[Campbell Ritchie]

prateek shaw wrote:. . . 1-You can throw any new unchecked exception which is not thrown by base method. I agreed with this point 100%. Advantage . . .

No, that is completely wrong. An overriding shou‍ld be a feasilbility‑preserving refinement, so for all circumstances in which the superclass' method is feasible, the subclass' method shou‍ld be feasible too. So the subclass' method shou‍ld never throw any Exceptions which the superclass method does not throw. I think that you will understand your four “rules” as one rule with “not” in, which I can write formally like this:-
∀e • e ∈ Exceptions ⇒ ¬canThrow(superclassMethod, e) ⇒ ¬canThrow(subclassMethod, e)
Remember that ⇒ associates to the right, and you can use the contrapositive rule to turn the right part of that implication round:-
p ⇒ q ≡ ¬q ⇒ ¬p
∴ ¬canThrow(superclassMethod, e) ⇒ ¬canThrow(subclassMethod, e) ≡
canThrow(subclassMethod, e) ⇒ canThrow(superclassMethod, e)
Let us imagine that your subclass method declares it might throw a file not found exception (=FNFE). If the superclass method declares IO exception (=IOE), well evey FNFE is an IOE too, because of inheritance, so you can legitimately say that if your subclass method throws an FNFE, that is included in the IOEs which the superclass method declares.
Now, we all know that you can get an ArithmeticException or a NullPointerException unexpectedly in any method, which is why those exceptions are unchecked. You can always say that the superclass method might throw such an Exception. What you cannot do is something like this:-

@Override
public boolean equals(Object ob)
{
   if (ob == null)
   {
      throw new NullPointerException(...);
   }
   return ob.getClass().equals(this.getClass()) && ...;
}

You are saying that you will not accept nulls as arguments to this method, but the superclass' method accepts nulls, and the general contract for equals says it accepts nulls. What you now have is an incorrect overriding, which breaches the Liskov Substitution Principle. You must have some method of handling nulls which will not cause any exceptions to be thrown and which will also ensure that the first method call in line 8 runs without exceptions.

Your “rule” 1 shou‍lg have been written

The compiler does not notice unchecked exceptions.

There is a difference between something which compiles because the compiler does not notice an error and something which is correct code.

Only write throws Exception if you don't know what sort of Exception subclass methods might throw, so that probably only applies to interface.

A slightly different situation exists if you declare a reference to the interface.

public interface Interface
{
   void foo(String s) throws Exception;
}

class Foo implements Interface
{
   public void foo(String s)
   {
      // ...
   }
}

class Bar implements Interface
{
   public void foo(String s) throws SQLException
   {
      // ...
   }
}

When you declare a reference of type Interface, how is the javac tool to know what sort of Exception is thrown by the implemented method? Is it supposed to go through all the code you have and find how many classes implement that method? Can you look ahead and evaluate this sort of thing?

Interface intf;
if (Math.random() < 0.5)
{
   intf = new Foo();
}
else
{
   intf = new Bar();
}
intf.foo("prateek");
intf = new SomeTypeImplementingThatInterface();
intf.foo("Campbell");

What sort of Exception does the next method throw? How can the compiler predict that? In order to make sure that every potential exception is handled, it requires you deal with plain simple Exception.

[J. Kevin Robbins]

Campbell Ritchie wrote:
∀e • e ∈ Exceptions ⇒ ¬canThrow(superclassMethod, e) ⇒ ¬canThrow(subclassMethod, e)
Remember that ⇒ associates to the right, and you can use the contrapositive rule to turn the right part of that implication round:-
p ⇒ q ≡ ¬q ⇒ ¬p
∴ ¬canThrow(superclassMethod, e) ⇒ ¬canThrow(subclassMethod, e) ≡
canThrow(subclassMethod, e) ⇒ canThrow(superclassMethod, e)

Damn math majors. You just made my head explode before my first cup of coffee. I'm going to reveal my lack of education here and admit that I've never even seen this kind of notation. Can you explain what I'm looking at here? Would I need to take 3 years of calculus to understand it?

[Stephan van Hulst]

This is propositional calculus. It's actually not too complicated.

∀e • e ∈ Exceptions ⇒ ¬canThrow(superclassMethod, e) ⇒ ¬canThrow(subclassMethod, e)

This means: For each e: (e is an Exception) implies that ((superclassMethod can not throw e) implies that (subclassMethod can not throw e))

p ⇒ q ≡ ¬q ⇒ ¬p

This is a logic rule that says: saying "if statement p is true, statement q must be true" is equivalent to saying "if statement q is false, p must be false".

Applying this rule to simplify the first statement yields

∀e • e ∈ Exceptions ⇒ canThrow(subclassMethod, e) ⇒ canThrow(superclassMethod, e)

In English, this means: If e is an exception and subclassMethod can throw that exception, then superclassMethod must be able to throw that exception.

∴ means "therefore", and is used to indicate a logical conclusion.

[J. Kevin Robbins]

Thank you. I actually understand that explanation. I wish I had learned calculus. It seems fascinating. I recall seeing that scene in "The Day the Earth Stood Still" where Keanu Reeves and John Cleese are scribbling equations on the board as if they are having a conversation in numbers. Is that really possible?

[prateek shaw]

Thanks for reply.

I read your post twice or thrice and i am trying to understand your point. To be honest in your written paragraph i have learned new things ,Thanks for this.

Regarding first point. I wrote like this  

1-You can throw any new unchecked exception which is not thrown by base method. I agreed with this point 100%. Advantage . . .

And you have written below.

The compiler does not notice unchecked exceptions.

Honestly , as common and normal mind thinking i can say both outcome is same. Which mean we both agreed that unchecked exception is exception which compiler ignore or i can say they meant to work like this so that we have more control at run time.
However your way of saying is better than mine so i do agree with this. Thanks.
Sorry to say but i did not understand below formula. However it look super cool , i wish i could understand.

∀e • e ∈ Exceptions ⇒ ¬canThrow(superclassMethod, e) ⇒ ¬canThrow(subclassMethod, e)
Remember that ⇒ associates to the right, and you can use the contrapositive rule to turn the right part of that implication round:-
p ⇒ q ≡ ¬q ⇒ ¬p
∴ ¬canThrow(superclassMethod, e) ⇒ ¬canThrow(subclassMethod, e) ≡
canThrow(subclassMethod, e) ⇒ canThrow(superclassMethod, e)

I did not know about "Liskov Substitution Principle". thanks , i will read more.
And last one , i understand what you are saying , but this is not what i asked.
I was asking , if super class is throwing exception this does not mean that child class which is overriding method should also throw exception. And here we are talking about checked exception.
My only counter question is overriding,this is nothing but redeclaring same method in child class ,we have n rule for this.
We have also one rule where child class ignore exception, if you called this method directly you do not need to use try catch. This is what my whole point is.
Here i am not saying anything wrong but what is reason for this. This is what i am asking ?
Even i go one point here which is related to same concept.
First let me give example.
1-

public void m3(){
		try{
			int i =10;
		}catch(IOException io){
			
		}
	}

2-

public void m3() throws IOException{
		
	}

The first code will not compile and second will compile. If i see first one , compile is smart enough to find out that there is no code in try block which throw this checked exception. But in second code which compiler is not thinking same way. Is there any reason ? See we already have Exception class to use then both will behave same.

public void m3() throws IOException{
		try{
			int i =10;
		}catch(Exception io){
			
		}
	}

Thanks

[Stephan van Hulst]

J. Kevin Robbins wrote:Thank you. I actually understand that explanation. I wish I had learned calculus. It seems fascinating. I recall seeing that scene in "The Day the Earth Stood Still" where Keanu Reeves and John Cleese are scribbling equations on the board as if they are having a conversation in numbers. Is that really possible?

I suppose it's possible, but it would be very similar to knowing exactly what a person is going to say before they finish their sentence. Mathematics is actually just like language, except it allows less ambiguity. Scenes like that have been done more often (another cool one is in Good Will Hunting), but I doubt it happens in real life.

[Campbell Ritchie]

Stephan van Hulst wrote:This is propositional calculus. It's actually not too complicated. . . .

Propositional calculus, not differential or integral calculus, which are different. And of course it is not complicated. Otherwise I would not have understood it
I never did a Maths major, and when I used to help teach Formal Aspects of Computer Science, we expected the undergrads to understand that after a couple of hours of instruction. Now, you have had a couple of minutes of instruction from Stephan and understood it
FACS was the abbreviation for the course and people on it were called FACSists which I of course pronounced Fascists.

[Campbell Ritchie]

prateek shaw wrote:. . . as common and normal mind thinking i can say both outcome is same. . . .

It is like the difference between driving through town at 78mph and driving through town at 78mph and passing a traffic policeman. The outcome might be the same in both cases that you will cause a nasty accident. But in the second case (policeman) you will slow down to a safer speed to avoid getting caught. It does not make it better or worse whether the policeman is there to notice or not. It is the responsibility of the driver to drive at a safe speed.
The javac tool is programmed on the belief that most RuntimeExceptions mean there is an error somewhere in the code, and that error shou‍lf be corrected rather than the Exception being handled. If you get an IO Exception because your network cable has pulled out of the wall, you can correct the problem by reconnecting the network. If you get a null pointer exception, you will need to go back to your code and get rid of the null or something like that. You probably cannot try again without altering the code. That is why unchecked exceptions are ignored by the javac tool: there are so many of them the code would be unmanageable. If you get a checked exception the error can be sorted out while the program is running. If you get an unchecked exception you shou‍ld allow the program to terminate and go through the code for the error. If there is an unchecked Exception in the subclass method, you will have to change the code somewhere.

A few hours ago, I wrote:. . . canThrow(subclassMethod, e) ⇒ canThrow(superclassMethod, e). . .

The semantics of the ⇒ operator in logic are that it is only false if you have true to its left and false to its right. If the subclass doesn't throw an exception (false on the left), then the whole expression is true, irrespective of what is on the right of the ⇒. That means that if the subclass method doesn't throw an Exception, then it doesn't matter whether the superclass does or does not throw an exception. Let's turn that round, so everybody other than Stephan and me can understand it:-

If the superclass method might throw an Exception, it is all right for the subclass method not to throw that Exception. If the superclass method doesn't throw an exception, then the subclass method doesn't throw that exception.

Unchecked exceptions: these are like driving. It is the driver's responsibility to drive safely, so it is the programmer's responsibility to avoid unchecked exceptions as far as possible.

In the case I showed with the equals method, you have a user who comes to the equals method knowing he has always passed null to that method and it has returned a value. Now all of a sudden, he passes null and gets an Exception. He will complain

All other equals methods accept null as an argument. Why don't you?

...and call you things they might print on other websites He is right. You don't want unexpected Exceptions. It will annoy him even more if you say, “Well, it was an unchecked Exception and the code compiled all right.”

[Campbell Ritchie]

A few minutes ago, I wrote:. . . The javac tool is programmed on the belief that most RuntimeExceptions mean there is an error somewhere in the code . . .

Well, at least that is the theory. You can read about it in the Java™ Tutorials. Remember, this is a controversial feature; if you search for “Checked Exceptions. An experiment which failed.”, you will find a completely different opinion.
And remember that other languages do not support the same distinction between checked and unchecked Exceptions.

And remember that either, books or tutorials which say, “It is an unchecked exception; you can ignore it”, are mistaken, or, you have misunderstood what they say.