Una Alternativa para los Try Catch | Result Pattern
HTML-код
- Опубликовано: 26 сен 2024
- En este video te mostraré una técnica que te servirá como alternativa a los Try Catch.
🍺 Mis Cursos de PROGRAMACIÓN: hdeleon.net/cu...
📚 Mis Libros
📖 Aprender a Programar con C#: hdeleon.net/li...
🤖 Mi Setup
🖥️ Mi Monitor: amzn.to/3dtnDkk
⌨️ Mi Teclado: amzn.to/3BtjKnq
⌨️ Mi Deck elgato: amzn.to/3dvEKC3
🎧 Mis Orejeras: amzn.to/3BwQYm0
🎤 Mi Micrófono: amzn.to/3qPvFHh
Si quieres apoyarme y darme para una cerveza puedes hacerlo por aquí: paypal.me/Hecto...
Puedes apoyarme desde 0.5 USD al mes uniéndote como miembro al canal aquí: / @hdeleonnet
🐦Twitter: / powerhdeleon
🌎Mi Sitio web: hdeleon.net
📻Raw Radio en Spotify: open.spotify.c...
#programación #dev #programming
Mis Cursos de Programación: hdeleon.net/cursos-premium/
Mi Nuevo Libro: hdeleon.net/libro-aprender-a-programar-con-c-hector-de-leon/
hoy me dio ganas de darle like a los últimos 30 videos de hdeleon. no se. simplemente me provocó. listo mas de 60 videos con likes. éxitos mi pana.
Interesante. Al Garbage Collector le encanta esto.
0:02 joder eso si es de ganster, de gansters!
ESA PERRA ESTA LOCA!!!
jajajaja real gangsta sharp xD
@@mrmonkey09 areh
A que canal se refiere? habla muy rápido y no le entiendo.
@@Blacklight0369 midudev
Excelente para manejar la lógica dentro de Stride Engine.
Todo conocimiento es apreciado siempre aprendemos algo nuevo y le agradezco, ahora desde mi humilde punto de vista creo que es algo que nativamente usamos y mis profesores lo llamaban validación sobre todo porque antes no existia Try Catch, en el tipico ejemplo de un algorimo que pide un nombre y lo imprime en pantalla pero si el nombre contiene numeros que imprima en pantalla "nombre invalido" y mucho antes de eso para validar que no se deborden las variables, etc.. La única diferencia es que usa un unico objeto generico para devolver.
Yo venía de NET y usaba exceptions para todo... luego estuve con Golang y me encantó utilizar este patrón...
Yo soy usuario de rust y JavaScript, uso tanto result como try/catch. Y tengo que decir que usar result te hace escribir mucho más código que try/catch, aunque sea más rápido y más seguro. Querer micro-optimizar lenguajes a veces no es la mejor idea, ya que pierdes claridad en el código. En muchas ocasiones si lo que busco es compatibilidad y rapidez me voy por el lenguaje de alto nivel, y si quiere rapidez, no micro-optimizo, directamente uso rust. El micro-optimizar es una puerta muy grande, podrías no acabar nunca. Y para los haters, no he dicho que que el patrón esté mal ni que nunca se deba usar, I love rust
Confirmo
try catch usado sin conciencia, es lo mismo que cuando te ven los polis, te dan tu calentadita con tehuacanazos, te entamban, te dan tu bienvenida, y luego en la investigación sale que tu no hiciste nada, y entonces llega el "usted disculpe". O cuando anunciaron "La La Land" como ganadora a mejor película, para segundos después ya con la gente arriba del escenario tuvieron que arreglarlo.
Me parece que validar códigos de error, está muy lejos de la micro-optimización; try catch queda bien en espacios donde es casi imposible prevenir un error.
Imaginate que haces el programa para un robot que hace operaciones, haces cortes por aquí y por allá, el robot se detiene con la excepcion: PatientIsDeadException; cuando pudiste haber validado todos los signos vitales durante el proceso.
@@ricardoangelesgomez8667 programas al ahí se va entonces, una programación correcta usa las excepciónes como se debe, todo lo demás son validaciones. Sr. 🤖
@@ricardoangelesgomez8667 en ese caso uso rust, y se acaban los problemas. Si lees el final de mi comentario, no digo que el patrón nunca deba usarse, si no que, no debemos usarlo siempre a la ligera
Bravo, hace tiempo lo usaba sin saber el nombre técnico. 100% aceptado
Mas alla de su velocidad, creo que hace mucho mas legible el codigo, y te permite separar el flujo de trabajo y flujo de validacion.
Grande hector
En el laburo estaba implementando una integración con varias api y justamente he usado un enfoque similar para la estructura de la salida sin plantearme que fuera un patrón de diseño.
Me llevo un par de ideas de aquí para acabar de mejorarlo❤
Así funciona Go! Aunque un caso excepcional sería un Panic!
El origen del try-catch era para evitar tener que escribir código para evaluar el valor de retorno después de cada llamada a función y tener código mejor estructurado.
En lenguajes de tipo fijo, es un problema ya que el valor de retorno para indicar error no forma parte del "DOMIINIO", como sería el caso de la división por 0, pero en lenguajes de tipo fijo se puede devolver otro tipo de datos en caso de que haya error, por ejemplo una instancia de la clase Error o algo así. En ese caso el código sin try-catch tiene que revisar que el valor devuelto sea un int y no un Error, pero en muchos lenguajes también es un problema por la separación entre tipos nativos como int y clases como Error.
// js implementation that throws exceptions an validates its arguments
function divide( x, y ){
if ( typeof(x) != 'number' ) throw "X not a number";
if ( typeof(y) != 'number' ) throw "Y not a number";
if ( y == 0 ) throw "Division by 0";
return x / y;
}
Buenas Hector! Me gusto el video. Puede ser útil para manejar excepciones de negocio, o cualquier capa menos infraestructura ya que ahi si pueden surgir errores que no tenemos idea de como prevenirlos. No te voy a mentir jajaja vine con expectativa de solucion a ese nivel pero es claro que no se puede. Y un requisito para este tipo de excepción es conocer muy bien el negocio o la app. Sos crack! Saludos
En C# ese IsSuccess lo uso cuando en el httpClient ejecutó la invocación al REST de cualquier API y se debe consultar si fue exitoso entonces deserializa el resultado.
Soy programador en Javascript y este patrón la mayoria de programadores suele usarlo de forma inconsciente. La lógica te lleva a hacerlo. Por otro lado, el try catch lo uso casi exclusivamente en código asincronico async await, con fetch especialmente, y muy rara vez como un fallback para realizar alguna operación de limpieza de algun componente el cual no se si existe y cuyo resultado no importa falla o no.
Programador de Javascript???? Marge, trae la escopeta!!!
Osea, hago scripts en Javascript, perdón por la ofensa, me gustaría saber que es ser programador para ti.
@@RCSoftMedia jajajaj era una mala broma solo, como es un video de c#
Excelente explicación
¡Buen video master! De gran manera te ayuda mucho a evitar poner a cada momento un try catch, pero algo muy importante a considerar es que hay errores que salen de nuestras manos por las que "romperían" la forma de trabajar el patrón. agregando un manejador de excepción te ayuda muchísimo y evitas que preocuparte por estar viendo los posibles errores que salen de nuestras manos, obvio también tienes que poner de tu parte al momento de generar algún código de status distinto a 200. pero con esta explicación es una buena base para poder ir empezando poco a poco y tener más control en tus sistemas. @hdeleonnet estupendo video, muchas gracias por tu forma de enseñar se agradece!
Exacto, yo utilizo muchísimo los try catch en Laravel para los métodos de consultas de eloquent, que de otro modo serían casi imposibles de detectar
Hola , muy bueno el video , la forma evolucionada de este concepto en programacion funcional son las llamadas monadas , que son tipos que envuelven otros tipos , como el optional o maybe en algunos lenguajes de programacion , implementan metodos como bind , map y flatmap para acceder al valor.
Me encanta la librería de language common por el result que maneja en c#
ñaaaaa Midu Rules!
Épico el video, un saludo.! ahora excepcionalmente toca de ver como lo aplico en PHP 😅
Excelente para mejorar la logica
Muy interesante el result pattern. Muchas gracias!
...jajajajja... "[...] que JavaScript apesta!" Me haz hecho dia. Te adoro!
Muchas veces escucho tus tutoriales para reirme de tus ocurrencias.
Un abrazote!
gracias por el contenido, muy bueno, me ayudó a entender mejor en q momentos debo o no aplicar un try catch, y una excelente alternativa usando el result pattern, veo q esto es también aplicado en Golang
jajajjajja muy buena presentacion, saludos desde Buenos Aires
Este patrón es muy interesante. Es buenísimo para manejar el comportamiento del fetching. Gracias por compartir esta información, profe. Saludos!
gracias profe.
grande Hector siempre se aprende con tus explicaciones
barbaro, me encanto la clase, sencilla práctica
excelente para usar en GO
Es un patron es muy bueno, yo uso una variante con sealed class en Kotlin y agregando un tercer estado para el loading para reacionar Ui en cada estado de una manera sencilla sin tener propiedades separadas
Sin duda siempre tienes contenido de calidad. Hoy aprendí algo muy útil, lo implementare en java y veremos que tal me va en test coverage, pienso que me puede ayudar bastante, gracias Hector.
uso patter matching en elixir la verdad es algo que amo y uso mucho en todo mi código el único problema es la repetición de código lo cual puede ser un problema y aveces hay que reescribir funciones pero es un problema de skills de mi parte. me recuerda al meme "Look What They Need to Mimic a Fraction of Our Power"
Es curioso como estaba haciendo cosas similares en mi código, sin darme cuenta que estaba haciendo uso de un patrón.
Esta muy bien, imagino que lo que voy a decir es algo que ya consideraste, este comentario esta dirigido a los demas que quieran utilizar este patron, para que tengan cuidado, el unico problema que veo es que es muy facil de utilizar de manera incorrecta, cualquiera podria utilizar la propiedad Value sin revisar si tuvo exito o no y no tendria problema porque se le asigna el valor por defecto (ouch), seria bueno modificar un poco el getter de la propiedad Value para que lance una excepcion al intentar utilizar el valor cuando ha fallado aunque puede añadir un poco de overhead tal vez puede ser algo que se ponga solo en builds de depuracion
Amo que Go no tenga excepciones
Súper claro! Muchas gracias 😄👍🏼
Excelente!, aprendí algo nuevo para mi
Muy bueno el video, pero tengo una consulta de ejemplo, cómo se aplicaría éste patrón con una consulta sql que retorna un error? Habría que hacer una por una las evaluaciones posibles? Por ejemplo, verificar que no se pase el fk repetido o que un campo no puede ser null, etc. sería controlar muchas cosas a mano o hay una opción diferente que no estoy dando cuenta?
Gracias cabezón!
Buen video Héctor! Me recuerda mucho a Either
Muchisimas gracias Hector, siempre trayéndonos contenido nuevo de calidad y cosas que aportan mucho abrazo grande!!!
Jajajajaja 😂😂😂 la introducción estuvo súper. Me rei mucho
Excelente video. Tengo una aplicación api hererdada de hace años que tiene ese patrón, pero nadie me lo explico. Sería ideal si pudieses de alguna forma integrar incluso un trycatch en ese patrón para los casos excepcionales
Hola, yo estoy usando excepciones en una API porque me cree un Middleware que las captura y devuelve un json con un objeto Result muy similar al que has creado en el video. Usar excepciones es extremadamente cómodo porque se devuelve el mensaje de error al controlador sin importar la arquitectura de la app y sin tener que crear flujos complejos o controlarlos con if como el que describes arriba.
Pero por contra, hay que lanzar y capturar la excepción que es un objeto más o menos pesado y luego convertirla en un objeto Result lo cual efectivamente es muy lento.
Es muy parecido a la lógica de las Monads IO
Todo esto me recuerda a las validaciones con DataNotations. Buen video bro
La libreria ErrorOr hace esto, no sabia que era un patron de diseño
Excelentee el dato.!
Hola señor Hector de Leon, usted si que es mañoso con los try/catch.
Muy bueno el video! Siempre estuve en esa disyuntiva con el try catch si usarlo para todo lo que puede salir mal y tomarlo como error, o controlar lo que se que puede pasar y dejar el try catch para otras situaciones. En lo personal me queda comodo manejar cualquier error por try catch (ya sea excepcional o esperado). Supongo que tambien será segun el caso. Saludos!
El
Video esta muy bonito sin embargo yo utilizo esa lógica en conjunto con un objeto respuesta T que encapsula una clase T, sería interesante ver un video con el objeto respuesta
Muchas gracias guapo tu conocimiento me ha hecho mejorar como programador y sigue compartiendo este conocimiento
Primer like y primero comentario, :3 eres un crack gracias !!!
Como todo en la programación : según la necesidad y proyecto. Igual siempre es bueno saber las diferentes formas de tratar errores y aplicar la más optima según necesidades. Recuerda siempre considerar cuidadosamente las implicaciones y sopesar las ventajas y desventajas antes de optar cual usar
Haskell mi estimado
Una implementación que me gusta más y es la que uso yo en mi trabajo es que la clase Result reciba 2 genéricos, 1 para el success y otro para el error y así puedes aprovechar este patrón para cualquier caso y elegir para cada caso lo que quieres devolver no solo en caso exitoso, si no también en caso de error
Buenas!! Pero esto no reemplaza los try catch. Si las consistencias las controlas manualmente. Un error no controlado puede terminar el programa. Si me gustó mucho como plantilla de respuesta para mejorar el manejo de errores en la aplicación. Muy buenos tus videos!!
El objetivo del video es mencionar que un try catch esta hecho para cosas excepcionales, y hay errores que no lo son y esto puede controlarlos, lamentablemente no todos los lenguajes tienen Generics.
Me encanta aplicar result pattern. La única pega que tienes es que no es tan fácil aplicarlo como REST.
Es decir, no tiene mucho sentido devolver una respuesta HTTP 200 cuando el Success está puesto como "false". Por lo demás, es una maravilla para unificar todas las respuestas de un sistema
No tiene nada que ver un 200 con un success, en todo caso devolverías un 400
supongo que con el if de IsSucess puedes decidir dónde retornar 200 y dónde retornar 400, etc incluso ir más allá y agregarle el StatusCode a la clase Result
Entonces si hay una situación excepcional dejamos que el try catch lo meneje?
Gracias Hector of Lion 🦁🔥
Como entraría un Result con una transacción y su rollback por ejemplo
Que interesante, muchas gracias
Que buen tema gracias por el vídeo mi gordo bello
Puedes dar un ejemplo pero esta vez en JavaScript? 😘
Creo que ha faltado hablar del encadenamiento de funciones (programación funcional) con ejemplo sobre ello. Por ejemplo, en JavaScript se puede ver fetch.then().then().then().catch() y el catch se aplica a todos los then ya que en los then se usa este patrón.
Entonces mijo. ¿Cuando vas a realizar un video de un proyecto real en Laravel con arquitectura hexagonal?
Hola Héctor muy bueno tu video, podrías hacer un video probando el ide idx.dev para programación backend.
Gran trabajo mate
Muy buen video, de lo mejor! Sigue así.
muchas gracias por el video
Golang lo trae por defecto
Lo intentare replicar en Java apoyandome en Gemini
Hola me parece interesante ese patron, siento que Go lo usa por defecto, pero mi problema con el es como evitar que la catidad de ifs (ya sea anidados o no) crezca rapidamente?, algun consejo para este problema?
Hector esto me acuerda cuando usan un try catch en un fetching y cree que le va avalidar hasta cuando la contraseña es incorrecta😅
Muy bueenoo, nunca me gustaron los ty catch! sabés si se usa en java también?
Genial gracias
Pero a fin de cuentas al trabajar con apis, si sucede algo ya ahora sí tendrías que exponer en la petición el error, si estás debuggueando, es más legible identificar las peticiones que te marcan error, sino tendrías que ir de una en una para verificar cuál es el que no fue exitoso correctamente. Esto decae en tener un middleware que resuelva el result pattern. De igual forma es más sencillo que el front lea los códigos de errores mediante un middleware si tiene directamente la falla del error.
Error != Excepción
@@hdeleonnet claro, pero me refiero a que es raro regresar una petición en un api que diga que terminó con estus 200, pero no fue exitoso
Genial video, tengo una duda. En caso ocurra un error inesperado, como se puede controlar sin try catch.
Buen video hector!
ah Carai esto es lo que tienes que hacer en golang por defecto, porque no hay try catch, interesante, el mismo patron estaba usando en php con laravel, asi que se llama "result Pattern" muchas gracias
El macho! jajaja
La clase Result generalmente se utiliza para encapsular el resultado de una operación que puede tener éxito o fallar PERO no es un patron como Factory u Observer.
Hace años que los patrones de diseño dejaron de ser 23
@@hdeleonnet Pero no es un patron en el sentido tradicional, es una clase lo que usas. Te concedo que es una practica util , que resuelve problemas y maneja errores, pero hasta ahi.
Existe alguna aplicación que uno pueda programar con un celular?
Hector me gusta pero me asusta, a todo este rollo como le manejamos a CancellationTokenSource
Un crack!
buen vídeo
Hola, pero estas validando errores conocidos por ti como programador, como validas un error que no sabes que va a suceder o retornar? Digo usando el exception del try catch, pero un ejemplo estaria muy bien.
Es lo que siempre hago en mis códigos, vengo de C y allí es lo que hay, pero ¿Cómo implementarías en la función Read un File.Move si puede dar excepción la propia API de .NET?. Hace poco me paso siguiente, necesitaba mover un fichero y yo comprobaba los permisos
FileIOPermission filePermissions = new FileIOPermission(FileIOPermissionAccess.Read |FileIOPermissionAccess.Write, source);
filePermissions.AddPathList(FileIOPermissionAccess.Read | FileIOPermissionAccess.Write | FileIOPermissionAccess.Read, target);
El caso es que no me devolvía error, podía leer, pero al llamar a File.Move daba una excepción WindowsInternal.
La propia función de .net Move hace la misma comprobación, pero al llamar a la función de C++ interna de move daba el fallo, en ese caso no se me ocurre como hacerlo sin try-catch.
Bro..busco un programador que me haga un proyecto y estaré pegando es claro no...ponte en contacto con migo para hablar del tema
Cuanto tiempo me tomaria aprender c# si soy desarrollador backend en python y node ?, muy buen video por cierto me encanto 😅
828266378282636728837373828 años
@@hdeleonnet😂😂 la mejor respuesta
Muchas definiciones en los lenguajes de programación son incluso hasta arbitrarias, por ejemplo, se demonizo la sentencia GOTO en favor de las estructuras de control condicionales y de loop, sin embargo posteriormente introducieron el try-catch que no es otra cosa que un GOTO disfrazado.
Es un tanto ridiculo que demonizaran al GOTO, ya que a final de cuentas todo se implementa con instruciones JUMP en el nivel de las instrucciones del CPU, o sea GOTO. Todo gran poder es una gran responsabilidad, y este es un ejemplo concreto donde cedieron el uso de ese poder al compilador y consideraron al programador muy tonto para poder utilizarlo.
es que javascript apesta wn jajaja, midudev lo sabe pero igual si tenemos chamba tenemos que usarlo, ni hablar de php y uso php a diario.
Por eso llegó Typescript para amortiguar la cagada de JS 😂, Aguante C#
Javascript apesta solo para los júnior, a mi gustan todos los lenguajes todos tienen ventajas y desventajas, a veces cuando no necesitas que tus datos estén fuertemente tipados por ejemplo cuando interactuas con apis externas que no sabes que tipos de datos te devuelve los lenguajes no tipados son los reyes yo programo en todos.
Para ser judto, las nuevas versiones de PHP tienen mejores funcionalidades que Javascript. Lamentablemente nadie las usa y la mayoría de las codebases están hechas en 5.4 y/o sin ninguna semblanza de orden. :')
Y uno cuando trabaja tiene que mantener esas codebases legacy :')
Aprendí como se llama ese patrón, porque lo venía usando en golang y no sabía que tenia nombre
Asi es la filosofía de Go.
Tremendo Hector!, yo utilizo este patrón muy útil en mis proyectos, pero te quería consultar, por ejemplo en mi caso uso el try catch en situaciones donde mi repositorio falla en la ejecución a base, dandome como resultante una SQLException , para lo cual tengo un evaluador para ciertos casos como por ejemplo:
if (ex.Number == 2627 || ex.Number == 2628)
{
return new ResultObject(HttpStatusCode.Conflict, data: "Unique constraint conflict error");
}
en estos casos, es una buena implementación tanto del patrón result como del try catch? o existe otra alternativa?.
Abrazo master!
La excepción debe ser dejada en donde nosotros no podemos controlar que pase algo, como en tu caso, algo ajeno a ti no lo controlas, esta bien una excepción
@@hdeleonnet Muchisimas gracias!
Para operaciones asíncronas es mejor el try catch
Uy no, vas a desbordar la memoria.
@@hdeleonnet una duda que me surge al usar el patrón result, en el que caso que este haciendo una llamada a un endpoint y por algún motivo se cae la conexión, como atraparía ese error con el patrón result? Como haría con el patrón result para evitar que ante cualquier inconveniente no me tumbe el servicio? Eso es algo que controla el try catch y algo que no veo que pueda hacer el result.
Chat-GPT me dijo que las mejoras practicas es con try catch, a quien le hago caso? al poderosisisisisismo chat-gpt o le hago caso al cabezón de las cervezas?
Ya he demostrado como se colapsan los sistemas con excesivos try catch, hacer caso al chatgpt
Quizás puedas investigar cómo los try/catch están implementados en tu lenguaje favorito... en casi todos es lo mismo, pero algunos implementan "artificios" para poder compensar de manera más "amable" las afectaciones cuando una excepción ocurre.
Hay un refrán que aplica muy bien aquí; más vale prevenir que remediar... quizás antes de ejecutar ese código super critico convenga hacer todas las validaciones pertinentes, de esa manera acotas mejor las posibles excepciones, para que realmente ese error sea excepcional: algo que no tenías forma de prevenir, y en el catch tener una rutina para revertir todo.
@@hdeleonnet chatgpt es nuestro pastor
pd: Fue puro sarcasmo
err != nil supremacy
Si pero si en un proyecto usas muchas librerías o APIs que tienen códigos de excepción prediseñados, para aplicar el patrón Result se deben picar a mano uno por uno cada uno de los casos de error. La ejecución es más rápida pero el código se puede volver muy largo e innecesariamente verboso. Mucho trabajo para poca recompensa. Creo que este patron es adecuado para aplicaciones pequeñas donde no existan muchos errores o, si de verdad la velocidad es un problema y la lógica no se puede optimizar mejor que hay que meterse hasta "tan" bajo nivel.
Pero que dices, si todo endpoint Http usa esto. Nadie ha dicho que no se usen Excepciones. Se dijo que no las usen para todo. Cuando hagas un sistema grande y que sea utilizado por millones verás como las Excepciones matan tu cpu