The short answer
Integral types (JLS 4.2.1) are categorically different from floating point types (JLS 4.2.3). There may be similarities in behavior and operations, but there are also characteristically distinguishing differences such that confusing the two can lead to many pitfalls.
The difference in behavior upon division by zero is just one of these differences. Thus, the short answer is that Java behaves this way because the language says so.
On integral and floating point values
The values of the integral types are integers in the following ranges:
127, inclusive, i.e.
32767, inclusive, i.e.
2147483647, inclusive, i.e.
9223372036854775807, inclusive, i.e.
'\uffff' inclusive, that is, from
The floating-point types are
double, which are conceptually associated with the single-precision 32-bit and double-precision 64-bit format IEEE 754 values and operations.
Their values are ordered as follows, from smallest to greatest:
- negative infinity,
- negative finite nonzero values,
- positive and negative zero (i.e.
0.0 == -0.0),
- positive finite nonzero values, and
- positive infinity.
Additionally, there are special Not-a-Number (
NaN) values, which are unordered. This means that if either (or both!) operand is
- numerical comparison operators
- numerical equality operator
- numerical inequality operator
x != x is
true if and only if
double, the infinities and
NaN can be referred to as:
The situation is analogous with
On when exceptions may be thrown
Numerical operations may only throw an
Exception in these cases:
NullPointerException, if unboxing conversion of a
null reference is required
ArithmeticException, if the right hand side is zero for integer divide/remainder operations
OutOfMemoryError, if boxing conversion is required and there is not sufficient memory
They are ordered by importance, with regards to being common source for pitfalls. Generally speaking:
- Be especially careful with box types, as just like all other reference types, they may be
- Be especially careful with the right hand side of an integer division/remainder operations
- Arithmetic overflow/underflow DOES NOT cause an exception to be thrown
- Loss of precision DOES NOT cause an exception to be thrown
- A mathematically indefinite floating point operation DOES NOT cause an exception to be thrown
On division by zero
For integer operation:
- Division and remainder operations throws
ArithmeticException if the right hand side is zero
For floating point operation:
- If the left operand is
0, the result is
- If the operation is division, it overflows and the result is a signed infinity
- If the operation is remainder, the result is
The general rule for all floating point operation is as follows:
- An operation that overflows produces a signed infinity.
- An operation that underflows produces a denormalized value or a signed zero.
- An operation that has no mathematically definite result produces
- All numeric operations with
NaN as an operand produce
NaN as a result.
There are still many issues not covered by this already long answer, but readers are encouraged to browse related questions and referenced materials.