Duda de diseño sobre excepciones

[Franpanozzo]

Buenas haciendo el ejercicio de monedero me surgió una duda:

Vieron que varias veces en el código se pregunta por ejemplo si el saldo o tal restricción no cumple (ej: limite de extracción) se lanza una excepción. Sacando el tema de los code smells, no podría ser que todas los posibles casos que tiraban una excepción particular ahora sean objetos en una lista e implementen una interfaz con su respectiva validación? Y si no cumple alguna tiras una excepción mas general. Se perdería esa especificación en la excepción, pero capaz el código queda mejor. Podría ser esto o es mejor tener un chequeo de cada caso para tener excepciones mas especificas y saber donde estoy fallando?

Saludos!!

[nanderson87]

Hola @Franpanozzo

Es una posibilidad pero creo que esto que comentas de que finalmente lanzarías una excepción mas general, es algo a tener en cuenta.

Aunque en este ejercicio no vamos a estar capturando las excepciones para darle un tratamiento (y tampoco nos va a interesar), sí podemos pensar que quien la este capturando para hacer algo es posible que vaya a querer identificarlas de una mejor manera.

Por ejemplo, podemos pensar que el tratamiento ante una excepción del tipo SaldoMenorException sea llevar al usuario a un flujo donde pueda elegir un monto menor a extraer. Mientras que ante una MaximaCantidadDepositosException por ahí simplemente nos vamos a limitar a informarle que no puede hacer más depósitos en el día y terminar ese flujo.

[Franpanozzo]

Perfecto, por lo que me decís capaz en otros requerimientos vas a tener que capturarlo y hacer diferentes cosas. Pero entonces en este caso, que no están los requerimientos de que yo o alguien podría capturarlo desde otro lado, seria valido implementar lo que dije o es preferible identificarlas de mejor manera con estos ifs??

[nanderson87]

En este caso vamos a querer tener identificadas las excepciones con sus respectivos tipos.

Por otro lado monedero esta pensando para poder ejercitar sobre la refactorización del código. En la etapa de refactor lo que se busca es simplificar el código y hacerlo más extensible pero sin cambiar la funcionalidad que teníamos antes de empezar con él mismo. Dicho lo anterior ir por el camino de cambiar las cosas para tener una excepción genérica rompe un poco con este concepto. Ya que antes del refactor, por ejemplo, si se intenta ingresar un monto negativo ibamos a recibir una excepción del tipo MontoNegativoException y después de hacer ese cambio vamos a recibir una excepcion del tipo ExcepcionGenerica (por poner un nombre).

Por esta razón no sería correcto cambiar los tipos de excepciones que ya estan en el ejericio y el momento en que se lanza las mismas porque entrarían en conflicto con el concepto de hacer un refactor.

Por último, esto no quiera decir que NO se puedan hacer mejoras/simplificaciones sobre los flujos donde estan involucradas las excepciones. Como puntapié podemos ver que tanto en el método poner como sacar de la clase Cuenta se esta haciendo la misma verificación y si se cumple la misma se esta lanzando la misma excepción. Seguramente ahí ya tenemos una oportunidad para mejorar nuestro código.

De nuevo podes plantear las mejoras que creas convenientes pero al verlo como un refactor esos cambios no deberían modificar ni agregar nueva funcionalidad que no tenías antes de empezar el refactor.

[Franpanozzo]

Claro ósea mi duda iba mas allá del enunciado y lo que pedía, sino del tema este del diseño de excepciones no desde un refactor sino ya desde el principio del diseño, pero por lo que me contas es según los requerimientos lo que se quiera hacer. Entonces en este caso que estamos haciendo refactor no habría que cambiar esas decisiones por lo que comentas, se entendió perfecto muchas gracias!!