¿Por qué, en la aritmética de Java, el desbordamiento o desbordamiento nunca arrojará una excepción?

Durante la operación aritmética de Java, JVM no arroja Underflow o Overflow Exception. Muchas veces nos encontramos con resultados inesperados y nos preguntamos qué salió mal.

Mientras que en el caso de la tecnología .NET tenemos excepción de Desbordamiento y Desbordamiento.

Entonces mi pregunta es por qué Java no diseñó lanzar esta excepción durante la operación aritmética

Esta fue probablemente una combinación de factores:

  1. Los grandes lenguajes anteriores a Java usaban aritmética sin verificar. Los algoritmos conocidos propensos al desbordamiento numérico tendían a tener en cuenta el posible desbordamiento sin tener que recurrir a la aritmética comprobada.
  2. La aritmética comprobada introduce una sobrecarga significativa en los algoritmos que hacen un uso intensivo de las instrucciones aritméticas, lo que pondría a Java en una desventaja sustancial, especialmente para los puntos de referencia.
  3. Algunos algoritmos se basan en el desbordamiento / desbordamiento numérico silencioso. Si se verificaron las operaciones aritméticas, la reescritura de estos algoritmos podría convertirse rápidamente en algo no trivial.
  4. La aritmética comprobada no es necesaria para garantizar la seguridad de la memoria (a diferencia de otras comprobaciones JVM como punteros nulos y límites de matriz).

El entorno de ejecución virtual .NET (ahora parte del estándar ECMA-335) introdujo instrucciones separadas para la aritmética comprobada y no comprobada, lo que le permite abordar de forma independiente las preocupaciones de seguridad y rendimiento de los desarrolladores que trabajan en lenguajes administrados modernos.

Probablemente tiene que ver con el rendimiento como dijo Indoknight. Java proporcionó las herramientas para cuidar el desbordamiento, por lo que si necesita detectarlo podría hacerlo. También tiene LongInteger y BigInteger y puede usarlos para evitar sus desbordamientos int.

Debería ver esta respuesta de una pregunta similar en stackoverflow. ¿Cómo maneja Java los flujos y desbordamientos enteros y cómo lo verificaría?

Java se basó en C y C ++, que se basa en el ensamblaje. En ninguno de estos idiomas se lanza una excepción, en parte porque las Excepciones no estaban en esos idiomas cuando se diseñaron las operaciones aritméticas.

En primer lugar, es mucho más seguro utilizar un tipo más grande como long o double o BigInteger o BigDecimal y solo usar tipos más pequeños si realmente está seguro de que esto no es apropiado.

No tiene por qué ser un problema común si utiliza estos tipos más amplios.

Cuando Java se creó originalmente, los diseñadores de idiomas lo hicieron de esa manera. No estoy seguro de por qué, pero si lo hubiera tenido ciertamente tendría una penalización de rendimiento al generar Excepciones.

“La lección para los diseñadores de idiomas es que puede valer la pena reducir la probabilidad de un desbordamiento silencioso. Esto podría hacerse al proporcionar soporte para la aritmética que no se desborda silenciosamente. Los progtwigs podrían lanzar una excepción en lugar de desbordamiento, como lo hace Ada, o podrían cambie a una representación interna más grande automáticamente para evitar el desbordamiento, como lo hace Lisp. Ambos enfoques pueden tener penalizaciones de rendimiento asociadas. Otra forma de reducir la probabilidad del desbordamiento silencioso es respaldar la tipificación de objectives, pero esto agrega una complejidad significativa a el sistema de tipos [Modula-3 1.4.8]. ”

Cortesía: trampas y trampas de rompecabezas de Java por Joshua Bloch y Neal Gafter