Compilation error or Runtime exception?

[john smith]

class Eco {
public static void main(String[] args){
Eco e1 = new Eco();
Eco e2 = new Eco();
Eco e3 = new Eco();
e3.e = e2;
e1.e = e3;
e2 = null;
e3 = null;
e2.e = e1;
e1 = null;
}
Eco e;
}


In the above program, how 'would' I tell whether it will be a compilation error or Runtime exception ( caused by e2.e = e1 ), at compile time.
Thanks.

[Sagar Rohankar]

how 'would' I tell whether it will be a compilation error or Runtime exception ( caused by e2.e = e1 ), at compile time.

Firstly the compile time error is occurred , when something goes wrong according to the rules or code not adhered to syntax or semantics !(cant explain you more on this, please googled it) .

And runtime exception is because , while running the things are not same as we expected, then JVM complains !

Lastly, you ll required a lots of code writing practice, which makes you better programmer in future and you ll find this difference easier ,

[john smith]

Thank you for your response.

However, this code is a question in a certification book. The answer for the question suggests it is a runtime exception instead of a compilation error. I was thinking that the compiler would see a null pointer in the code and cause a compile error. Why is it a runtime exception instead of a compile time error?

Thanks.

[Sagar Rohankar]

Because , when compiler compiles the code, it saw everything is perfect, as per "rules" and and this statement e2.e = e1; has a valid reference "e2" , which pointing to nothing "null" object and retrieving its 'e' instance variable (object here) . This is fine as per compilers perspective.

When code actually runs, we are retrieving the 'e' instance variable , from an "null" nothing object, hence the JVM , complains that "he cant find the things as he expected" and he throws an runtime exception , stating "NullPointerException" ..

Hope this help !

[Ulf Dittmer]

Pointers being null is something that occurs at runtime; the compiler has no concept of what a particular piece of code might or might not do at runtime, so it doesn't try to guess what might go wrong. It can't do that in general anyway, so why bother doing it for simple cases where that's possible?