Una Alternativa para los Try Catch | Result Pattern

En este video te mostraré una técnica que te servirá como alternativa a los Try Catch.
🍺 Mis Cursos de PROGRAMACIÓN: hdeleon.net/cursos-premium/
📚 Mis Libros
📖 Aprender a Programar con C#: hdeleon.net/libro-aprender-a-...
🤖 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/HectorDeLeonGuevara
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.com/show/3obLU60...
#programación #dev #programming

[@hdeleonnet]

Mis Cursos de Programación: hdeleon.net/cursos-premium/ Mi Nuevo Libro: hdeleon.net/libro-aprender-a-programar-con-c-hector-de-leon/

[@exkalybur_dev]

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.

[@sebastiansanchez7177]

0:02 joder eso si es de ganster, de gansters!

[@franciscocarrera2028]

ESA PERRA ESTA LOCA!!!

[@mrmonkey09]

jajajaja real gangsta sharp xD

[@sebastiansanchez7177]

@@mrmonkey09 areh

[@Blacklight0369]

A que canal se refiere? habla muy rápido y no le entiendo.

[@juanmijaimemon]

​@@Blacklight0369 midudev

[@TheMatiasCu]

Yo venía de NET y usaba exceptions para todo... luego estuve con Golang y me encantó utilizar este patrón...

[@horacioramirez6872]

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.

[@malcubas1]

Bravo, hace tiempo lo usaba sin saber el nombre técnico. 100% aceptado

[@nicolasgajardo5966]

Súper claro! Muchas gracias 😄👍🏼

[@jnmldo]

Muy interesante el result pattern. Muchas gracias!

[@EnanoForro]

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

[@brandonicr6913]

Así funciona Go! Aunque un caso excepcional sería un Panic!

[@ampm5091]

Hace algunos años implementé sin conocerlo este patrón en los diferentes proyectos que trabajé, para mi resulto fundamental en las soluciones que presentaba, lo curioso es que mis jefes y compañeros lo miraban con desden. Yo lo implemente como una interfaz que agregaba a cada objeto para acoplarse a otros. Siempre retornaba un result para el caso en que fuera exitoso y un string y codigo de error cuando no.

[@ludwingguate]

Que buen contenido! Gracias Héctor!

[@maggot008]

Excelente explicación

[@CodeDibertzStride]

Excelente para manejar la lógica dentro de Stride Engine.

[@germannunez7282]

barbaro, me encanto la clase, sencilla práctica

[@carlosalbertobarreralugo]

Excelente!, aprendí algo nuevo para mi

[@jorgemar1469]

grande Hector siempre se aprende con tus explicaciones

[@xdxasq]

Que Bien, otro patron de diseño a la lista,👍👍👍👍👍

[@luisliquin6398]

jajajjajja muy buena presentacion, saludos desde Buenos Aires

[@AristeoIbarra]

Este patrón es muy interesante. Es buenísimo para manejar el comportamiento del fetching. Gracias por compartir esta información, profe. Saludos!

[@luceroemmanueling]

muchas gracias por el video

[@leviatanMX]

Excelentee el dato.!

[@OscarCedano]

Muy buen video, de lo mejor! Sigue así.

[@jairofernandez9920]

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

[@Miguel_Castaneda]

Gracias cabezón!

[@davemour]

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❤

[@rodolfotovartorres]

Muchas gracias guapo tu conocimiento me ha hecho mejorar como programador y sigue compartiendo este conocimiento

[@Lajy-Enterprise]

Épico el video, un saludo.! ahora excepcionalmente toca de ver como lo aplico en PHP 😅

[@RaimundoAraujoCorrea]

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.

[@nikcapo]

Programador de Javascript???? Marge, trae la escopeta!!!

[@RaimundoAraujoCorrea]

Osea, hago scripts en Javascript, perdón por la ofensa, me gustaría saber que es ser programador para ti.

[@nikcapo]

@@RaimundoAraujoCorrea jajajaj era una mala broma solo, como es un video de c#

[@JoseAlvaradoo]

Gracias Hector of Lion 🦁🔥

[@lorddesert]

Buen video hector!

[@EdgarOmarLopez-pp6xc]

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.

[@libertad_1214]

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

[@muremure]

Confirmo

[@ricardoangelesgomez8667]

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.

[@ricardoangelesgomez8667]

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.

[@muremure]

@@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. 🤖

[@libertad_1214]

@@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

[@alejandrafernandez8504]

gracias

[@cristiancalichio5335]

Muchisimas gracias Hector, siempre trayéndonos contenido nuevo de calidad y cosas que aportan mucho abrazo grande!!!

[@yoynootro]

...jajajajja... "[...] que JavaScript apesta!" Me haz hecho dia. Te adoro! Muchas veces escucho tus tutoriales para reirme de tus ocurrencias. Un abrazote!

[@AndresLobaton]

Que interesante, muchas gracias

[@BerlinSantos]

excelente para usar en GO

[@AlejandroRamirez-le3vr]

Jajajajaja 😂😂😂 la introducción estuvo súper. Me rei mucho

[@unicronos7]

Genial gracias

[@maisakurajima1886]

Excelente para mejorar la logica

[@ciberiori]

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.

[@crhistianbetetanavarro1689]

Buen video Héctor! Me recuerda mucho a Either

[@atherbsc5384]

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

[@isaaccorona1039]

¡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!

[@beamerboy7754]

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

[@emanuelmeza4290]

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!

[@atrox7329]

Me encanta la librería de language common por el result que maneja en c#

[@HewerthVengeance]

Un crack!

[@santosmarte]

Primer like y primero comentario, :3 eres un crack gracias !!!

[@alfonsobaqueiro]

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; }

[@soppyone5406]

Hola, recientemente estuve revisando y siguiendo tu curso de facturación. Me quede en el paso del timbrado, solo quería saber si sigue vigente la pagina que proporcionaste para el timbrado. No quisiera pagar y que no funcione. Me interesa bastante realizar unos timbres de prueba. Quedo atennto, gracias por leer

[@adokana_]

buen vídeo

[@santidogor]

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

[@YamilOrtega-rl9vb]

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

[@sgssergio]

Para el caso de web api, colo dice Hector se usa mucho este patrón, es buena practica definitivamente un Result personalizado para encapsular el menaje que se devuelva al cliente, por ejemplo la librería Ardelis.Result sirve para eso.

[@MoyRomero]

Todo esto me recuerda a las validaciones con DataNotations. Buen video bro

[@brayangomez4935]

Que buen tema gracias por el vídeo mi gordo bello

[@mercetoki]

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.

[@Boxccs21]

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.

[@yahi06]

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"

[@pablomagnavachi2961]

Muy bueenoo, nunca me gustaron los ty catch! sabés si se usa en java también?

[@danielvillalobos7171]

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

[@alicehope9231]

Lo intentare replicar en Java apoyandome en Gemini

[@wilfredorosario8750]

Hola Héctor muy bueno tu video, podrías hacer un video probando el ide idx.dev para programación backend. Gran trabajo mate

[@DiegoSasco]

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?

[@jorgealarconalvarez]

Amo que Go no tenga excepciones

[@ehcualquiera1377]

Hola señor Hector de Leon, usted si que es mañoso con los try/catch.

[@user-xs4th5rm6w]

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

[@eljoe182]

Puedes dar un ejemplo pero esta vez en JavaScript? 😘

[@diegodig9]

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

[@sebasContreras-em6np]

Genial video, tengo una duda. En caso ocurra un error inesperado, como se puede controlar sin try catch.

[@andryos5145]

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

[@franciscorafaelvillanuevaj6310]

Me parece interesante. Suelo hacer algo similar para evitar tener que lanzar excepciones en mi código cuando evaluo una condición en los if ... else. Por ejemplo si no existe un archivo o config del programa, se genera uno nuevo con valores por default, o si se el usuario ingresa un valor null o fuera de los límites esperados, se le pide que vuelva a ingrrsa un valor cual sea.

[@christianledesma2128]

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

[@hdeleonnet]

No tiene nada que ver un 200 con un success, en todo caso devolverías un 400

[@f.gabrielsosarozzi2661]

Es curioso como estaba haciendo cosas similares en mi código, sin darme cuenta que estaba haciendo uso de un patrón.

[@locotoazul]

Haskell mi estimado

[@luiscaraballo2815]

ñaaaaa Midu Rules!

[@user-ti1ez4yo5i]

El macho! jajaja

[@toni9305]

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

[@adolfomartin5456]

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.

[@rofernandez3535]

Entonces si hay una situación excepcional dejamos que el try catch lo meneje?

[@oswaldorafaelzamoraramirez6166]

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?

[@Parmenideano-sp5hl]

Early return

[@lara97196516]

Entonces mijo. ¿Cuando vas a realizar un video de un proyecto real en Laravel con arquitectura hexagonal?

[@pentest4fun]

Ok y ahora como lo hago en PHP? Nee ntc se comprende la logica muchas gracias por el contenido.

[@CarlosSosa-tj9fq]

La libreria ErrorOr hace esto, no sabia que era un patron de diseño

[@hazlotumismo1419]

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.

[@luisdimas9]

Es muy parecido a la lógica de las Monads IO

[@DestroyWolves]

Como entraría un Result con una transacción y su rollback por ejemplo

[@JuanPerez-qh7es]

Existe alguna aplicación que uno pueda programar con un celular?

[@WotansVolks]

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!

[@hdeleonnet]

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

[@WotansVolks]

@@hdeleonnet Muchisimas gracias!

[@MagnusRazer]

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.

[@hdeleonnet]

Hace años que los patrones de diseño dejaron de ser 23

[@MagnusRazer]

​@@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.

[@spartanzarazua117]

Hola Hector una duda y si la excepción la da una llamada a la base de datos, por ejemplo que el key no existe o que el tipo de dato no es compatible. ¿Cómo se procede a verificar eso y aun seguirían habiendo ventajas?

[@hdeleonnet]

Si tu key no existe deberías captarlo con un if, algo que si debe ser excepción es que la bd no responda o esté caída.

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.

[@hdeleonnet]

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

[@luisalbertoseguraavalos2993]

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.

[@jeancarlosluciano9211]

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😅

[@jorgeduran1886]

Cuanto tiempo me tomaria aprender c# si soy desarrollador backend en python y node ?, muy buen video por cierto me encanto 😅

[@hdeleonnet]

828266378282636728837373828 años

[@jorgeduran1886]

​@@hdeleonnet😂😂 la mejor respuesta

[@emiliowildberger7151]

Hector me gusta pero me asusta, a todo este rollo como le manejamos a CancellationTokenSource

[@martillonegro429]

Bro..busco un programador que me haga un proyecto y estaré pegando es claro no...ponte en contacto con migo para hablar del tema

[@alonsojl-12]

Asi es la filosofía de Go.

[@jhonnye.chinolacato9108]

Como hacer una peticion mediante el protocolo OUIJA??

[@cesarloyo1747]

err != nil supremacy