Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Narrowing of reference type

 
manu chandra
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

consider the following example:

public class A
{

public void m1()
{
System.out.println("class a");
}

}

public class B extends A
{
public static void main(String[] s)
{
A a=new B(); //This holds good.

B b=(B)new A(); //compile time no error but run time error;
}
}

My question is is there any use of doing a downcast like this just to avoid compile time error and to convert the code to bytecode?


 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No. All you are doing is postponing the error to runtime. You should (at great lengths) try to discover all errors at compile time, not try to put them off till runtime. So this is just bad.

Doing B b = (B)new A(); can never succeed because the A is not a B.
 
Paul Clapham
Sheriff
Posts: 21416
33
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my opinion there isn't any practical purpose to produce code which is guaranteed to crash when you run it.

There could be other purposes, though, for example if you weren't allowed to go home until your code compiled. Then you might want to produce bad code which compiles rather than good code which doesn't compile. However that situation isn't going to apply to made-up code with classes called A and B.
 
manu chandra
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So practically it means nothing? It does not have any advantage right?
 
manu chandra
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
manu chandra wrote: So practically it does not have any advantage right?And as far as i think its a bad practice
 
Ishan Pandya
Ranch Hand
Posts: 226
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I guess there are two public class in the same package. so it will give a compile time error.
and before casting it is better to check the with "InstanceOf" operator. which will give you a compile time safety.
 
Campbell Ritchie
Sheriff
Pie
Posts: 50225
79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ishan Pandya wrote:. . . check the with "InstanceOf" operator. which will give you a compile time safety.
At least two errors there, apart from the spelling error.
  • 1: We are not interested in compile time safety. We want as many errors as possible at compile time. The exception cannot occur at compile time anyway.
  • 2: All you achieve with the instanceof test, which cannot succeed, is obscuring the mistake in code which is never called. It is a version of if(false)... which the compiler cannot detect.
  •  
    Ishan Pandya
    Ranch Hand
    Posts: 226
    Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    ok Ritchie I understand. So is there any way to get compile time error for "Runtime ClassCastException"? as in can we stop ClassCastException at compile time? as you said that we want as many errors at compile time.
     
    Campbell Ritchie
    Sheriff
    Pie
    Posts: 50225
    79
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Generics is one method for moving runtime errors to compile time. But that may not be appropriate for this situation.
    The correct answer is to design your inheritance hierarchy correctly, so you can use polymorphism and not need those casts in the first place.
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic