Presentación para la charla "The Billion Dollar Mistake". En esta charla presento el origen de null, que problemas tiene y como solucionarlos en Java 8 con Optional.

1. T H E B I L L I O N D O L L A R M I STA K E

2. Q u i e n
s oy
a l o a i s a

3. • Más decepcionante que los Generics de Java
• Peor que la barra invertida de Windows
• Más problemático que la comparación en JS ===
• Más común que PHP
• Más lamentable que UTF-16
• Más escandaloso que MongoDB
• Más confuso que el Pre-Compilador de C
•El peor error se produjo en 1965!!

5. No eres un verdadero
programador
hasta que no has tenido un
NullPointerException

6. Tony Hoare
“ It was the invention of the null reference in 1965. At that time, I was designing the
first comprehensive type system for references in an object oriented language (ALGOL
W). My goal was to ensure that all use of references should be absolutely safe, with
checking performed automatically by the compiler. But I couldn't resist the temptation
to put in a null reference, simply because it was so easy to implement. This has led to
innumerable errors, vulnerabilities, and system crashes, which have probably caused a
billion dollars of pain and damage in the last forty years. ”
“I call it my billion-dollar mistake”

7. Que pasa con los nulls?

8. Que pasa con los nulls?
• NullPointerException es de lejos la excepción más común en Java
• Empeora la legibilidad llenando todo con chequeos de nulls
• Rompe la filosofía Java de ocultar a los desarrolladores los punteros.
• Es un agujero en el Sistema de Tipos
• No tiene un sentido semántico en particular.
• Es un mal modelo para representar la ausencia de valor para un lenguaje
estáticamente tipado.

9. “La ausencia de señal, nunca
debe ser usada como señal”
J. Bigalow 1947

10. null != Ausencia de valor

11. Problema típico en POO

12. Problema típico en POO
• Muchos ordenadores no tienen Soundcard.
¿Que devolvemos entonces?
• Comúnmente y como mala práctica, se suele usar
null para indicar la ausencia de SoundCard
• Con lo que el resultado será un NullPointerException en tiempo de
ejecución y el programa se parará.

14. ¿Como se ha resuelto en otros lenguajes ??
• Lenguajes como C# o Groovy tienen el “Safe navigation operator” ?.
• A la variable version se le asignará null si computer es null,
getSoundCard() devuelve null o getUSB() devuelve null.
• No es necesario escribir código complejo para chequear los null

15. Groovy - Elvis Operator ?:
• Es usado en casos simples cuando la variable necesita un valor por
defecto
• En el caso que .getVersion() nos devolviera null podríamos devolver
un valor por defecto de esta forma:

16. Otros puntos de vista
• Haskell: Incluye el tipo Maybe
• Maybe puede contener un valor de un tipo dado o nada, ya que
no existe el concepto de nulo
• En esencia encapsula a un Optional
• Scala: Similar con Option[T]
• Encapsula la presencia o la ausencia de un valor de un tipo T
• Tenemos que chequear si el valor está presente, lo cual es similar a
el chequeo de nulos.
• Fuerza al programador a controlarlo a través del sistema de
tipos

17. Y en Java ??
• Solución 1: (Guarrada)
• Desagradable a la vista
• Debemos chequear todos
los valores para evitar
que nos pase
• Todos estos checks están en medio de la lógica
• Disminuye la legibilidad del programa

18. Y en Java ??
• Solución 2:
Podemos utilizar notaciones para restringir los contratos:
@NotNull y @Nullable (Java 8 > No estandars)
• @Nullable nos recuerda la necesidad de introducir un chequeo de null cuando
llamamos a métodos que pueden devolver nulos.
• @NotNull nos establece un contrato por el que el método no puede devolver
null - Y sus parámetros no pueden ser pasados como null

19. Y en Java ??
• Solución 3:
Patrón NullObject
• Añade complejidad
• Hay que crear bastantes NullObjects dependiendo de la arquitectura

20. Y en Java ??
• Solución 4: (Otra guarrada)
Devolver Null
• Mala práctica
• Fuente de NullPointerExceptions
• No estamos pensando en el caso de que sea vacío

22. Que pasa en Java 8 ??
• java.util.Optional<T>
• - Inspirado en la idea antes vista de
Haskell y Scala
• - Es una clase que encapsula un valor
opcional

23. Optional
• Un Optional puede ser visto como un contenedor de un solo
valor que puede contener un valor o no.

24. Optional
• Computer puede tener o no soundCard
• SoundCard puede tener o no puerto USB

25. Optional
• Este nuevo modelo refleja si un valor dado puede estar ausente
• Establece la intención del API
• Optional no es para reemplazar cada referencia nula
• Es para ayudarnos a hacer un diseño más comprensible
• Con la firma del método podemos saber si es un valor opcional
• Te obliga a hacer frente a la posible ausencia de valor

26. Y ahora qué ??

27. Creando Optionals
• Si soundCard fuera null se lanzaría un NullPointerException
• Si soundcard fuera null el resultado del Optional sería empty

28. .ifPresent()
• Ejecuta algo si el Opcional contiene algún valor
Antes:
Ahora:

29. .isPresent()
• Devuelve true o false dependiendo si contiene o no valor
• Podemos usarlos de esta forma para evitar excepciones
• Este no es el mejor uso, ya que no es mucho mejor al chequeo de
nulos

30. .get()
• Nos devuelve el valor contenido en el Optional
• Si no hay valor almacenado, dará un NoSuchElementException
• Podemos usarlos de esta forma para evitar excepciones
• Este no es el mejor uso, ya que no es mucho mejor al chequeo de
nulos

31. .orElse()
Patrón típico:
• Usando un objeto Optional podemos escribir este código usando
orElse()
• Este método provee un valor por defecto si el Optional está vacío.

32. .orElseGet()
• orElse() ejecuta siempre el contenido y lo devuelve si es el caso, a
no ser que sea un lambda
• orElseGet() solo ejecuta el código si le toca actuar
• Puede dar un NullPointerException si lo que ejecuta devuelve
null

33. .orElseThrow()
- Lanza la excepción que le digamos si el Optional está
vacío.

34. .filter()
•El método filter() coge el valor como argumento
•Si el valor está presente en el Optional y la comprobación es true, el método filter()
devuelve el propio Optional
•Si el valor es vacío, devuelve un objeto Optional vacío
Antes:
Ahora:

35. .map()
• El valor dentro del Optional es pasado como argumento al método getUSB()
• Mientras que no pasa nada si está vacío
Antes:
Ahora:

36. .flatMap()
• getUSB() devuelve un objeto de tipo Optional<USB>
• Esto significa que el resultado de la primera operación map es un
objeto de tipo Optional<Optional<USB>>
• Como resultado, la llamada a getVersion() es inválida
Antes:
Ahora:

37. .flatMap()
• El propósito es aplicar el método de transformación sobre el valor del Optional y
"aplanar" el resultado de dos niveles de Optional en uno solo.

38. .flatMap()
• flatMap se utiliza para métodos que devuelven Optionals
• flatMap devuelve un Optional<USB> en lugar de un Optional<Optional<USB>>
• Podemos llamar a map() ya que getVersion() devuelve un String en vez de un objeto
Optional
Antes:
Ahora:

40. • El propósito de Optional NO es reemplazar cada referencia nula en el código
• El propósito de Opcional es el poder diseñar mejores APIs
• Nos fuerza a extraer su valor y gestionarlo en el caso de su ausencia
• Nos protege de nullPointerExceptions
• Simplifica el código
• Un nullPointerException en producción puede hacerte perder mucha pasta!!
Conclusiones:

41. R e c u r s o s
http://www.oracle.com/technetwork/articles/
java/java8-optional-2175753.html
http://es.slideshare.net/Stephan.Schmidt/better-
strategies-for-null-handling-in-java
http://es.slideshare.net/Yokomark/17-50372457
http://www.slideshare.net/mariofusco/monadic-
java
https://www.jetbrains.com/help/idea/15.0/
nullable-and-notnull-annotations.html
https://www.lucidchart.com/techblog/2015/08/31/
the-worst-mistake-of-computer-science/