Slides resumen de los puntos más importantes de los capítulos 7 y 8 del Clean Code de Uncle Bob Martin.

1. 7
MANEJO DE ERRORES

2. • Datos de entrada inesperados
• Conexiones que fallan
• Datos que faltan
“El manejo de errores es inevitable y necesario”

3. Clean Code
Si oculta/invade la lógica principal del programa está
mal.

4. Excepciones, no
códigos de error

5. Códigos de error
• Embarullan el código que invoca.
• Obligan a gestionar el error en la siguiente línea.
• En ocasiones se olvida.

6. Excepciones
• No enmarañan el código del que invoca.
• Se separa la lógica principal del manejo del error.
• Se pueden entender ambos códigos
independientemente.

7. Usar “Unchecked
exceptions”

8. Checked exceptions
• Obligan a declarar el lanzamiento de la excepción
en todas las llamadas hasta el catch.
• Un cambio a bajo nivel obliga a cambiar todas las
capas de alto nivel.
• Rompen la encapsulación.
• Son beneficiosas para una librería crítica o de bajo
nivel pero en una aplicación no merecen la pena.

9. Excepciones
• Provee contexto con la excepción. Indica el
mensaje. Información del error. Operación y el tipo
de error.
• Define las excepciones en términos de la
necesidad del que invoca. (Conexión fallida,
Servidor no disponible…).
• Envuelve (wrap) código ajeno para lanzar tus
propias excepciones.

10. Evita el caso especial
• SPECIAL CASE PATTERN.
• Cuando el caso especial puede ser incluido en el
flujo normal.
• Crea o configura una clase para que maneje el
caso especial y así evitar que el que invoca lo
maneje.
• Encapsulas el comportamiento especial.

11. Evita retornar null
• Al devolver null, obligamos al que invoca a
manejarlo.
• Al revolver null de un objeto considera “lanzar una
excepción” o usar un “Special case object”.
• Si es de un tercero, considera envolver el método y
“lanzar una excepción” o usar un “Special case
object”.
• Listado vacío en vez de null.

12. Evita pasar null
• Incluso peor que retornarlo.
• No hay buena forma de manejarlo.
• Obliga a comprobarlo siempre.
• Mejor evitar y prohibir pasarlos y manejarlos
cuando no quede otra opción.

13. 8
LÍMITES

14. Usar código de otros
Código externo
Código de terceros

15. Código de terceros
• Un código de terceros tiende a ser generalista y a
ser amplio en opciones y capacidad.
• En nuestra aplicación preferimos código enfocado
en nuestras necesidades y con lo mínimo
necesario. Forzando nuestros requerimientos de
negocio.
• P.E. La un array: Métodos innecesarios y
“péligrosos”, incluyen cualquier objeto.

16. Código de terceros
• Envolver (Wrapear) código de terceros.
• Encapsulamos la librería genérica usada.
• Ajustamos la interfaz únicamente a nuestras
necesidades.
• Podemos cambiar la estructura interna.

17. No se trata de
encapsular todo

18. Sino de no pasarlos
por todo el sistema
Solo dentro de clases o dentro de una familia de clases
relacionadas.

19. Tests de aprendizaje
• Prueba librerías de terceros mediante tests y de
forma aislada.
• Evita el problema de no saber si es fallo nuestro, de
la librería o un mal uso de la librería.
• Integrar y aprender a usar la librería son dos tareas
complicadas. Intentar atacarlo por separado.
• Puede ayudarnos a validar que todo sigue igual
tras actualizar a nuevas versiones de la librería.

20. Usar código que aún no
existe
• Pensar la interfaz deseada en el límite de lo
desconocido.
• Código más legado y enfocado en lo que quiere
conseguir.
• Una vez se define el api real adaptarla (ADAPTER) para
acomodarse a la actual.
• El ADAPTER encapsula la interacción con el API y
ofrece un único lugar de cambio cuando el API
evoluciona.

21. PATRON ADAPTER

22. Límites limpios
• En los límites ocurren cambios.
• El buen software acomoda los cambios con poca inversión
y “rework”.
• Al trabajar con código ajeno hay que tener especial cuidado
e intentar que el cambio no sea demasiado costoso.
• Hay que intentar que muy pocas partes del código accedan
al código de terceros.
• Wrapers o Adapters son técnicas que ayudan en esta
labor.

23. SIGUIENTE
9
Unit Tests