Por qué no uso "Exception" en mi código (parte 3) |

[@josemanuellucasmunoz8023]

Cuanta gente buena junta

[@charlie12486]

hace mas o menos un año recuerdo que en un curso de programación, me pidieron defender mi código y explicar por que no estaba usando en mi proyectos mvc las excepciones/try catch. Yo en mi defensa indicaba que tendían a ser lentos (vengo de gaming y ahí me han remarcado varias veces que evite lo mas que pueda el try catch por que se hacen validaciones en tiempo real todo el tiempo) y prefería manejar los casos borde con otros sistemas. Conclusión fui satanás por decir y hacer lo hice.

[@lechuck2011]

Ayer termine de refactorear un MVP que estoy haciendo para una idea personal eliminando esto y volver a manejar excepciones. Entiendo la ventaja de "ser explicito" pero me parece que hay que introduce mucho "ruido" en lograrlo. Obviamente, en equipos mas grandes genera muchas mas ventajas que un equipo de 1/2 personas.

[@PabloLargo]

Personalmente todas las excepciones relacionadas con lógica de dominio las manejo como checked exceptions. En PHP lo hago con PHPStan, así que me obliga a documentar correctamente que una función throwea o catchea sus checked exceptions 😊

[@scoowy8699]

Las checked exceptions de las que hablas es un concepto nacido en PHP? O es genérico? Me llamo la atención, yo trabajo con Python y me gustaría aprender a manejar de mejor manera las excepciones.

[@aldairmh4684]

@@scoowy8699 A lo que él se refiere por checked exception son las exceptions que son obligatorias poner en un try catch o tirar la excepción, las unchecked exceptions son aquellas que no es obligatorio poner los try catch.

[@scoowy8699]

@@aldairmh4684 ah entiendo, listo gracias!

[@jajujaja-ke6jv]

QUEEEEE DIJISTEEEEE !!!!??? p p p ach ach ... ni siquiera puedo nombrarlo ... anda a lavarte altiro las manos con cloro por haber escrito eso ... jajaja

[@v4ldevrr4m47]

Revisareè mis try catch ... son un atajo para validar y no lidiar de frente con todas las posibles causas y dejar abierta la exception a que lo atrape todo aunque muchas veces solo una cosa puede pasar ... Vale vale se trata de mejorar cada dia. Ser mínimamente mejor que ayer

[@Rainclock123]

Me parece una alternativa algo compleja para el valor que te puede dar. No sé cómo se decidirá en la capa de infraestructura, en el caso REST qué código enviar, entiendo que siempre será un 400, ya que únicamente se controlan errores de entrada. Este tipo de errores en aplicaciones EE se gestionan muy bien lanzando excepciones custom que no es necesario que se capturen programáticamente(trycatch), sino con interceptores / ErrorHandlers. Entiendo que para cualquier otro error 500 funcionaría similar (stackoverflow, errores de E/S, errores de memoria, etc). Me parece interesante porque sí que es verdad que es difícil mantener una lógica y límite en el uso de excepciones, pero me da la sensación que se centra mucho en errores del cliente, los cuales, sí trabajamos con api rest también se controlan bastante bien con especificaciones openapi para que cliente y servidor tengan las validaciones y vayan sincronizados en casa versión Y en caso de querer exponer una librería común fuerzas a que todos los contratos se acoplen a esta metodología, teniendo que entender el cliente el uso de ésta

[@FabianEduardoDiazLizcano]

Muy de acuerdo con tus comentarios, me parece que siempre debemos aprender a usar nuestras herramientas a profundidad. En mi experiencia me ha alcanzado con dejar subir las excepciones y tener un error handler para transformar esto a como lo entiende la capa HTTP, no se porque algo tan sencillo se vuelve un enorme problema; creo que no nos enseñan en la academia cual es la función de la excepciones y su correcto uso.

[@FabianEduardoDiazLizcano]

Estoy también de acuerdo de que no me alcanza con retornar un string cuando hay un error porque si tengo otro tipo de errores como puedo cambiar el status code en función de esto además que debo escribir un útil para traducir mis posibles errores a status code y estar invocando esto en todos mis controladores si alguien lo olvida sucede lo mismo que el try catch con exception donde ignoran los errores.

[@kainbizarro]

Por eso me gusta go

[@danielmondragon2476]

@kainbizzarro qué ofrece Go en este sentido?

[@kainbizarro]

@@danielmondragon2476 considero que es mejor la forma de manejar los errores que usa go vs a otros lenguajes de programación, por ejemplo los try/catch

[@troyaedgan]

Normalmente retorno results[status, message, data, traces]. Reglas de negocio las válido con if. Uso bloques try/catch para control de errores en tiempo de ejecución (algún problema en conversión de tipos, consultas a BD, apertura de archivos) atrapo estos datos lo asigno a los results y lo gestiono hacia arriba para al final poder imprimir esa traza de error. Nunca lanzo de manera intencional Excepciones (he visto mucho código que sí!). De esta forma cuido que el usuario no vea errores feos, que no esten expuestos los trace de mi aplicativo y en archivos de logs doy detalle de por donde fue pasando la petición y el trace del exception, útil para el monitoreo.

[@r.amilcarrivasmarquez2892]

No conozco java pero si el tipo Either no es de la librería estándar, lo tiene regado por todo sus código, con la dependencia que eso conlleva. El motivo principal para tener un objeto de valor es crear cohecion, pero con ese Either ya la perdieron. Creo que por no usar excepciónes están duplicando lógica defensiva y la clase tiene más de una responsabilidad. Exactamente para evitar esto, es que nacieron las excepciónes. En mi opinión era capturar la excepción en el controlador maperala a una página de error. Pero antes de eso capturarla en el servicio para el log. Ahora todos las API asta las de domino devuelven Either. Eso ya no es codigo facil de leer. Tendré que analizarlo bien, talvez esto es bueno y algo me estoy perdiendo (no es sarcasmo) como sea muchas gracias por el contenido. Carlos gracias por tu libro, me sirvió mucho. La segunda edición no he tenido tiempo de leerla pero sin duda estará genial.

[@noestamossolosnostenemosan1302]

Yo creo que try.. se debe de usar cuando el error no forma parte de algoritmo que debemos implementar, cosas excepcionales, cosas raras. Evita una cantidad de if of de case enorme. Lo normal debe tratarse con programación estructurada. Lo anormal con try catch. El try catch es una vuelta al maldito "goto" de los principios de la programación, invita a saltarse líneas de código que a lo mejor deberían ejecutarse.

[@JoeCast]

Exacto, para algún servicio externo o algo que escape como bien dices a nuestro algoritmo

[@nelsonscript]

Ó mejor construir un Interceptor para el manejo de excepciones y se respetan las excepciones, deja una solución legible y no depende de frameworks o definiciones de otras librerías que a futuro cambien, para el caso de validación de datos se hace con Guard. Responsabilidad Única dicen por ahi ;)

Geniales!

[@albuslrc]

Pucha tengo que aprender Java, me cuesta entender los conceptos. 😥

[@Anzhelone]

Que es lo que cuesta pa?

[@alexandee00717]

Yo igual prefiero el enfoque de usar un Result es más flexible y no soy fan de vavr XD (ojo que Scala me gusta)

[@danilotoro3997]

No le encuentro sentido el finally, si lo omitimos el código funciona igual no?

[@pazaresosset6348]

Poco control, es muy útil algo que se ejecuta haya excepción o no.

[@danilotoro3997]

@@pazaresosset6348 pero porque no lo dejas fuera del finally y ya?

[@pablotruffa588]

El finally se ejecuta aunque tengas una excepción. Si tenes algún recurso abierto como un stream de datos o tenes que hacer algunas limpiezas el finally puede ser tu aliado. Nadie quiere tener un memory overflow.

[@danilotoro3997]

@@pablotruffa588Mi punto es, quita la keyword finally y todo sigue igual. No hace falta usarlo, si de todos modos se ejecutará, para que usar un finally?

[@TheLexuguin]

Esto me suena a los monads en haskell

[@javi68yt2]

Porfa, Javi, cuida tu vocabulario .... 😉