CODEWITHSUNDEEP
javaoop
rb612
rb612

Reputation: 5563

Why is a cast exception fatal in Java?

According to this article:

In contrast to static type checking, dynamic type checking may cause a program to fail at runtime due to type errors. In some programming languages, it is possible to anticipate and recover from these failures – either by error handling or poor type safety. In others, type checking errors are considered fatal.

Java is an example where type checking errors are fatal. Why is Java (and maybe most static typed languages) so strict that it fails at runtime if a type error occurs? Let's say you upcast object A (actual type int) to type Object, and downcast to String. Compile-time checking will pass, but the runtime type check will fail with a fatal exception. This seems harsh, as it's not like an illegalArgumentException where the program literally cannot proceed (an invalid cast loses type safety but shouldn't be impossible). It would seem to me like the most optimal situation would be to throw a warning and then fail fatally if trying to call, say, String method indexOf on the integer object. Is there a reason for Java actually failing to proceed at runtime when trying to perform this invalid cast?

Upvotes: 3

Views: 1338

Answers (3)

user207421
user207421

Reputation: 310884

Java is an example where type checking errors are fatal.

No it isn't. You can catch them.

Why is Java (and maybe most static typed languages) so strict that it fails at runtime if a type error occurs?

Because that's what 'static typing' means; ditto 'strict typing'.

Let's say you upcast object A (actual type int) to type Object, and downcast to String. Compile-time checking will pass, but the runtime type check will fail with a fatal exception.

No it won't. It will fail with a ClassCastException.

This seems harsh, as it's not like an illegalArgumentException where the program literally cannot proceed (an invalid cast loses type safety but shouldn't be impossible).

But it is impossible. The cast cannot proceed. The way the object code is generated assumes so.

It would seem to me like the most optimal situation would be to throw a warning

It throws a ClassCastException.

and then fail fatally if trying to call, say, String method indexOf on the integer object.

Well it doesn't do that.

Is there a reason for Java actually failing to proceed at runtime when trying to perform this invalid cast?

The implementation is designed around the fact that the exception occurs.

Upvotes: 6

Erwin Bolwidt
Erwin Bolwidt

Reputation: 31269

It's not done like that because there is no benefit to what you're suggesting.

If you had code that could continue working in those situations, then your code is bad and superfluous, because the cast wasn't really necessary, as you're not doing anything specific with that type.

Typically languages are not designed to cater for unnecessary code.

There are lots of disadvantages, most notably performance: it wouldn't be possible to compile to machine code efficiently in a language that did what you describe.

Statically typed languages are typically faster than dynamically typed languages because knowing the type up-front makes many optimizations possible that wouldn't be possible otherwise.

Any what you are suggesting would make the language dynamically typed.

Upvotes: 2

Ken Slade
Ken Slade

Reputation: 343

I think the reason is to ensure that the programmer can locate the problem and fix it, ensuring that the software is correct. If you ignore a casting problem until you dereference, it could be too far down the road to track back easily.

Upvotes: 1

Related Questions