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.
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.
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
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
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❤
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.
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
...jajajajja... "[...] que JavaScript apesta!" Me haz hecho dia. Te adoro! Muchas veces escucho tus tutoriales para reirme de tus ocurrencias. Un abrazote!
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.
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; }
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
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
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.
¡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!
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.
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
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
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!
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.
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"
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
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
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
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.
Pero eso es sentido común, no se le puede dejar todo a los bloques Try Catch. Pero con result pattern como Puedes controlar un fetch a un enpoint que no está disponible? O como podemos evaluar la deserializacion de un json con ese patron? Por mencionar dos casos super simple. Que opinan ustedes? HDELON Eres uno de los mejores youtuber que enseñan contenido de C# te admiro! ❤
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
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
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.
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?
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
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.
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?
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.
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
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 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.
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?
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
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.
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.
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.
No se que es mejor si el contenido o el outro, rifado hermano!
Yo venía de NET y usaba exceptions para todo... luego estuve con Golang y me encantó utilizar este patrón...
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.
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.
Así funciona Go! Aunque un caso excepcional sería un Panic!
Interesante. Al Garbage Collector le encanta esto.
Bravo, hace tiempo lo usaba sin saber el nombre técnico. 100% aceptado
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
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❤
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
gracias profe.
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
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.
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
...jajajajja... "[...] que JavaScript apesta!" Me haz hecho dia. Te adoro!
Muchas veces escucho tus tutoriales para reirme de tus ocurrencias.
Un abrazote!
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.
Excelente para mejorar la logica
Muy interesante el result pattern. Muchas gracias!
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;
}
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
gracias por la informacion)# esta buena)) lo usare cuadno deba))
grande Hector siempre se aprende con tus explicaciones
Este patrón es muy interesante. Es buenísimo para manejar el comportamiento del fetching. Gracias por compartir esta información, profe. Saludos!
Épico el video, un saludo.! ahora excepcionalmente toca de ver como lo aplico en PHP 😅
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
excelente para usar en GO
Excelente!, aprendí algo nuevo para mi
barbaro, me encanto la clase, sencilla práctica
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.
Me encanta la librería de language common por el result que maneja en c#
¡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
jajajjajja muy buena presentacion, saludos desde Buenos Aires
Súper claro! Muchas gracias 😄👍🏼
Excelente explicación
Jajajajaja 😂😂😂 la introducción estuvo súper. Me rei mucho
Gracias cabezón!
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.
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
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
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!
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#
gracias
Todo esto me recuerda a las validaciones con DataNotations. Buen video bro
Buen video Héctor! Me recuerda mucho a Either
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"
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
Que buen contenido! Gracias Héctor!
Amo que Go no tenga excepciones
Excelentee el dato.!
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
Gracias Hector of Lion 🦁🔥
muchas gracias por el video
Que interesante, muchas gracias
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
Genial gracias
Es curioso como estaba haciendo cosas similares en mi código, sin darme cuenta que estaba haciendo uso de un patrón.
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.
Muy buen video, de lo mejor! Sigue así.
ñaaaaa Midu Rules!
Pero eso es sentido común, no se le puede dejar todo a los bloques Try Catch. Pero con result pattern como Puedes controlar un fetch a un enpoint que no está disponible? O como podemos evaluar la deserializacion de un json con ese patron? Por mencionar dos casos super simple. Que opinan ustedes?
HDELON Eres uno de los mejores youtuber que enseñan contenido de C# te admiro! ❤
Muchisimas gracias Hector, siempre trayéndonos contenido nuevo de calidad y cosas que aportan mucho abrazo grande!!!
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
empezamos fuerte jaslkdfjas
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.
La libreria ErrorOr hace esto, no sabia que era un patron de diseño
Que buen tema gracias por el vídeo mi gordo bello
Lo intentare replicar en Java apoyandome en Gemini
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?
Buen video hector!
Haskell mi estimado
Hola señor Hector de Leon, usted si que es mañoso con los try/catch.
Hola Héctor muy bueno tu video, podrías hacer un video probando el ide idx.dev para programación backend.
Gran trabajo mate
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
Primer like y primero comentario, :3 eres un crack 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
Muchas gracias guapo tu conocimiento me ha hecho mejorar como programador y sigue compartiendo este conocimiento
Un crack!
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?
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.
Puedes dar un ejemplo pero esta vez en JavaScript? 😘
buen vídeo
Genial video, tengo una duda. En caso ocurra un error inesperado, como se puede controlar sin try catch.
El macho! jajaja
Entonces si hay una situación excepcional dejamos que el try catch lo meneje?
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
Excelente para manejar la lógica dentro de Stride Engine.
Muy bueenoo, nunca me gustaron los ty catch! sabés si se usa en java también?
Ok y ahora como lo hago en PHP? Nee ntc se comprende la logica muchas gracias por el contenido.
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.
Asi funciona dart se maneja en muchas cosas la programación funcional, tengo una implementación muy robusta pero le falta ajustes
Es muy parecido a la lógica de las Monads IO
Golang lo trae por defecto
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?
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.
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😅
Entonces mijo. ¿Cuando vas a realizar un video de un proyecto real en Laravel con arquitectura hexagonal?
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
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!
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.
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.