Está interesante. Nunca me había planteado agrupar los lenguajes según su tratamiento de errores. Sin embargo, hay un detalle que sí habría que comentar. Con otros casos no puedo hablar, pero del "Devolver valor y error", que ponéis a Go como ejemplo, una de las desventajas que indicáis es el de la no propagación. Realmente no es exacto. El retorno clásico para estas cosas es lo que indicáis: valor, error = funcion_que_falla(); Sin embargo se puede silenciar o ignorar el error: valor, _ = funcion_que_falla(); En este caso, si la función devuelve un error el programa entra en el "modo pánico" (ése es el nombre oficial), que es básicamente una excepción no controlada en lenguajes como Java. La función actual termina inmediatamente y se propaga la excepción a la función superior. Si esta no la controla, esto se repite hasta llegar al main y el programa se cerrará. Igual que ocurre en Java. Por tanto, al menos en Go, sí existe la propagación. Ignoro qué ocurre en Rust u otros lenguajes.
De hecho, no. En go si haces error suppressing no significa que se llame la routine panic(), simplemente lo ignora. Para hacer panic y que detenga todo el trabajo en la goroutine (i.e. virtual-thread like en Java 21) lo tendrias que hacer tu explicito en el codigo all llamar panic(ERROR)/log.fatal(ERROR). Y tambien, el mecanismo de recuperacion (recover) no funciona muy bien en programas con varias goroutines corriendo sino se administran adecuadamente los goroutines. No es igual a lo que ocurre en Java. En donde se lanzan panics sin que sea explicito es cuando haces type casting sin un check. Ejemplo: someString := someAnyVal.(string) // will panic if someAnyVal is not string someString, ok := someAnyVal.(string) // will NOT panic, use ok bool value to check cast state
@@alonsoruiz6315 No hace tanto que estoy aprendiendo Go, yo soy más de Php. Parece que esto lo había entendido mal. Gracias por la corrección, lo repasaré.
muy de acuerdo con vuestro punto, de hecho hace poco me pique una clase Validated (que funcionaria como un Result digamos) en TS y considero que es una forma muy limpia de deshacerse de excepciones bajo casos en los que el flujo de la app va a estar controlado.
Quería aclarar que en el caso de Rust hay dos formas de propagar el error, el keyword yeet que está en fase de prueba y el operador ? que lleva desde 2021 aproximadamente. Esta bueno el video, dejo el comentario para que se propague el video también! Saludos 😆
Otra cosa es que si bien en el video hacen pattern matching para tratar el error también se puede hacer de forma imperativa como Go de if resultado.is_error() u otras cosas más avanzadas, Rust tiene muchos mecanismos para manejar el error dependiendo de que tan verboso, imperativo o funcional quieran las cosas. Como extra revisar la librería thiserror que es casi una convención su uso. No solo documentas, sino que te permite propagar los errores de forma automagicamente. Igualmente usar el ? es un poco trampa porque los otros lenguajes no tienen eso, pero bueno, son facilidades que da el lenguaje y su uso es muy divulgado dentro de la comunidad.
En c++ si una excepcion no es capturada se llama a std terminate y afecta el stack unwinding ( se deja de llamar a destructores y no se liberan recursos...dependerá de la implementación de la librería standar= comport no definido). Funcionando en un sist operativo, podría no funcionar en otro
Ostras xD btw.. yo creo q en java con excepciones, checked y unchecked, con excepciones personalizadas y con Optional, estamo' mas que bien ( creo.. mi humilde opinion..) con throws en la firma creo que es buena data no se xq no serìa suficiente .. a mi me cierran todas estas opciones que java brinda creo que usandolas todas y correctamente no se necesitaria mucho mas. En el caso de Exceptions peronalizadas no propagaria tanto o no? podemos modelar el dominio creo sin problemas.. interesante el caso de las notifications xa codigos con mucha compeljidad de manejo de excepciones.. me intriga no la conocia ni me tocó mucho la necesidad de cerca pero es bueno conocerlo.. puedo equivocarme pero es mi humilde opinion .. ostras xD Salu2 desde Argentina, muy bueno el canal.
Siempre he usado exceptions como patrón para errores y no errores casos de uso alternos y no ha habido complejidad en implementación ni en lectura, de hecho es la que más recomiendo pero también el Either con un enfoque no tan de izqueirda, derecha sino más de quien representa error y quien no, pero al final la facilidad de usar exceptions es mejor, el tema es que por ejemplo en JavaScript este amigo puede tener un performance y datos adicionales de track
Claro, Either al final es otra Monad, Rust tiene Option que puede ser Algo o Nada, y para el caso de operaciones puedes usar Result, tienes Ok o Err. La implementación es un enum, pero lo hace tan magico y sencillo que despues que lo aprendes se vuelve intuitivo.
Lo único en contra de un tipo Result en TypeScript es que las funciones asíncronas siempre devuelven una Promise, ergo tendrías que hacer un doble wrapping el cual puede dificultar la lectura, aparte de que es una forma muy poco convencional de trabajar como comentáis, pero todo es ponerse
Hay una librería en TypeScript que se llama Effect que implementa errores como valores (y otras cosas de programación funcional y concurrencia), aunque si la usas te toca inundar todo tu código en una librería de terceros.
@@germandavid2520 ufff, eso tiene un peligro enorme. Mañana dejan de dar soporte y te lo comes con patatas. Es como usar Zod o Typebox para cualquier cosa que no sean DTOs y similares. Mala idea en mi opinión
Hombre, no. No van por ahí los tiros. El objetivo es que, con un mínimo de orden, diferencies correctamente entre capas de abstracciones. Así en cada una de ellas tengas una idea clara de qué es lo que se está haciendo. No es que estés programando menos. En todo caso a futuro, cuando te toque entender y modificar lo que hacía.
@@maximotejedapozo9335 no necesariamente. Insisto, dependerá del nivel de abstracción de la aplicación donde te estés moviendo.
3 месяца назад+8
Para que rizar el rizo, las excepciones funcionan muy bien y para eso estan, eso de andar propagando errores manualmente está de más, aparte existen los errors handlers que funcionan con excepciones en la mayoría de frameworks decentes y es por algo, para que complicarse más la vida y mejor ocupar ese tiempo en algo más productivo.
No se trata de complicar, sino de tener un código con resultados más determinísticos. Cuando un método tira una excepción, no podés typearlo en la firma del método. A nivel de consumidor no sabés lo posibles errores que se pueden dar. Si bien la mayoria de frameworks traen esos "error handlers", no significa que sea lo más correcto. Que bonito es leer un código explìcito y no que sea como un "goto" tirando excepciones. Las excepciones, en mi exp, se usarían más para casos realmente excepcionales que no deberian ocurrir, asi en tu metrics los loggeas y no los llenas de puros errores que sabes bien que pueden suceder, aunque esto último igual se puede omitir con excep.
@@dylangrijalva944de hecho si es lo más correcto, usar checked exceptions, ya firma tu método salvó que el lenguaje no lo permita ya es más un problema del lenguaje
Si bien Java tiene lo de especificar en la firma de la función que excepciones puede lanzar no todos los lenguajes que usan excepciones tienen esto, en TypeScript por ejemplo es muy difícil saber que lanza excepción y que no y aun mas difícil saber que específicamente que tipo de excepciones lanza, a esto en ingles le llaman hidden control flow, vas a ciegas y es posible que te enteres que una excepción existe cuando tu código ya esta en producción. En mi opinion los errores como valores son lo mejor y creo que Rust tiene la mejor implementación , en Rust siempre vas a saber si una función retorna error y el compilador te va a obligar a que manejes el error o lo ignores de forma explicita. Mucha gente por ejemplo se queja de que en Go hay que escribir demasiado if err != nil {}, pero no se da cuenta que si intentaran escribir el mismo código en otros lenguajes tendrían que poner try {} catch () {} por todas partes, la cosa es que en Go cuando ves la firma de la función sabes de una vez si puede haber error o no, en muchos lenguajes con excepciones no puedes saberlo.
@@germandavid2520 Algo para agregar es el tema del ?, es un shortcut para propagar en Rust, hace transformaciones a tipos escalares y todo, una maravilla. El error handling de Rust es algo que se trabaja muy bien en general.
Me encanta que hagan este video ya que hice un comentario al respecto en el video anterior de manejo de errores
Está interesante. Nunca me había planteado agrupar los lenguajes según su tratamiento de errores.
Sin embargo, hay un detalle que sí habría que comentar. Con otros casos no puedo hablar, pero del "Devolver valor y error", que ponéis a Go como ejemplo, una de las desventajas que indicáis es el de la no propagación. Realmente no es exacto. El retorno clásico para estas cosas es lo que indicáis:
valor, error = funcion_que_falla();
Sin embargo se puede silenciar o ignorar el error:
valor, _ = funcion_que_falla();
En este caso, si la función devuelve un error el programa entra en el "modo pánico" (ése es el nombre oficial), que es básicamente una excepción no controlada en lenguajes como Java. La función actual termina inmediatamente y se propaga la excepción a la función superior. Si esta no la controla, esto se repite hasta llegar al main y el programa se cerrará. Igual que ocurre en Java.
Por tanto, al menos en Go, sí existe la propagación. Ignoro qué ocurre en Rust u otros lenguajes.
De hecho, no. En go si haces error suppressing no significa que se llame la routine panic(), simplemente lo ignora. Para hacer panic y que detenga todo el trabajo en la goroutine (i.e. virtual-thread like en Java 21) lo tendrias que hacer tu explicito en el codigo all llamar panic(ERROR)/log.fatal(ERROR).
Y tambien, el mecanismo de recuperacion (recover) no funciona muy bien en programas con varias goroutines corriendo sino se administran adecuadamente los goroutines. No es igual a lo que ocurre en Java.
En donde se lanzan panics sin que sea explicito es cuando haces type casting sin un check.
Ejemplo:
someString := someAnyVal.(string) // will panic if someAnyVal is not string
someString, ok := someAnyVal.(string) // will NOT panic, use ok bool value to check cast state
@@alonsoruiz6315 No hace tanto que estoy aprendiendo Go, yo soy más de Php. Parece que esto lo había entendido mal.
Gracias por la corrección, lo repasaré.
Qué lindo volver a ver a Go por el canal! Muy buen vídeo
ya estas en un trabajo de programador cobrando 288k por estos videos?Sus aportes me dilatan la tuberia una cosa mala
muy de acuerdo con vuestro punto, de hecho hace poco me pique una clase Validated (que funcionaria como un Result digamos) en TS y considero que es una forma muy limpia de deshacerse de excepciones bajo casos en los que el flujo de la app va a estar controlado.
¿En PHP cuál sería la mejor práctica para "devolver valor y error", tanto en clases como en funciones fuera de las clases (sin POO)?
En Java también se puede definir en la firma del método que excepción puede lanzar con throws
Quería aclarar que en el caso de Rust hay dos formas de propagar el error, el keyword yeet que está en fase de prueba y el operador ? que lleva desde 2021 aproximadamente.
Esta bueno el video, dejo el comentario para que se propague el video también! Saludos 😆
Otra cosa es que si bien en el video hacen pattern matching para tratar el error también se puede hacer de forma imperativa como Go de if resultado.is_error() u otras cosas más avanzadas, Rust tiene muchos mecanismos para manejar el error dependiendo de que tan verboso, imperativo o funcional quieran las cosas.
Como extra revisar la librería thiserror que es casi una convención su uso. No solo documentas, sino que te permite propagar los errores de forma automagicamente.
Igualmente usar el ? es un poco trampa porque los otros lenguajes no tienen eso, pero bueno, son facilidades que da el lenguaje y su uso es muy divulgado dentro de la comunidad.
En c++ si una excepcion no es capturada se llama a std terminate y afecta el stack unwinding ( se deja de llamar a destructores y no se liberan recursos...dependerá de la implementación de la librería standar= comport no definido). Funcionando en un sist operativo, podría no funcionar en otro
Ostras xD btw.. yo creo q en java con excepciones, checked y unchecked, con excepciones personalizadas y con Optional, estamo' mas que bien ( creo.. mi humilde opinion..) con throws en la firma creo que es buena data no se xq no serìa suficiente .. a mi me cierran todas estas opciones que java brinda creo que usandolas todas y correctamente no se necesitaria mucho mas. En el caso de Exceptions peronalizadas no propagaria tanto o no? podemos modelar el dominio creo sin problemas.. interesante el caso de las notifications xa codigos con mucha compeljidad de manejo de excepciones.. me intriga no la conocia ni me tocó mucho la necesidad de cerca pero es bueno conocerlo.. puedo equivocarme pero es mi humilde opinion .. ostras xD Salu2 desde Argentina, muy bueno el canal.
Siempre he usado exceptions como patrón para errores y no errores casos de uso alternos y no ha habido complejidad en implementación ni en lectura, de hecho es la que más recomiendo pero también el Either con un enfoque no tan de izqueirda, derecha sino más de quien representa error y quien no, pero al final la facilidad de usar exceptions es mejor, el tema es que por ejemplo en JavaScript este amigo puede tener un performance y datos adicionales de track
Claro, Either al final es otra Monad, Rust tiene Option que puede ser Algo o Nada, y para el caso de operaciones puedes usar Result, tienes Ok o Err.
La implementación es un enum, pero lo hace tan magico y sencillo que despues que lo aprendes se vuelve intuitivo.
Lo único en contra de un tipo Result en TypeScript es que las funciones asíncronas siempre devuelven una Promise, ergo tendrías que hacer un doble wrapping el cual puede dificultar la lectura, aparte de que es una forma muy poco convencional de trabajar como comentáis, pero todo es ponerse
Hay una librería en TypeScript que se llama Effect que implementa errores como valores (y otras cosas de programación funcional y concurrencia), aunque si la usas te toca inundar todo tu código en una librería de terceros.
@@germandavid2520 ufff, eso tiene un peligro enorme. Mañana dejan de dar soporte y te lo comes con patatas. Es como usar Zod o Typebox para cualquier cosa que no sean DTOs y similares. Mala idea en mi opinión
@@germandavid2520 También esta rustic
Faltó que hablaran de la trazabilidad de los errores
La melena de Javier no deja concentrarme ayuda.
el hecho de que el retorno en c sea un argumento de salida pasado por referencia no da ningún problema
Efectivamente yo aprendí primero a hacer error handling con códigos de error y las excepciones me siguen costando fjkñdsajf
Ventaja -> código implicito -> magia
Desventaja-> código explícito -> complejo
Es curioso programar y que la ventaja sea no tener que programar 😂
Hombre, no. No van por ahí los tiros.
El objetivo es que, con un mínimo de orden, diferencies correctamente entre capas de abstracciones. Así en cada una de ellas tengas una idea clara de qué es lo que se está haciendo.
No es que estés programando menos. En todo caso a futuro, cuando te toque entender y modificar lo que hacía.
@@luquillasnano si es como dices entonces, explícito > implícito
@@maximotejedapozo9335 no necesariamente. Insisto, dependerá del nivel de abstracción de la aplicación donde te estés moviendo.
Para que rizar el rizo, las excepciones funcionan muy bien y para eso estan, eso de andar propagando errores manualmente está de más, aparte existen los errors handlers que funcionan con excepciones en la mayoría de frameworks decentes y es por algo, para que complicarse más la vida y mejor ocupar ese tiempo en algo más productivo.
No se trata de complicar, sino de tener un código con resultados más determinísticos. Cuando un método tira una excepción, no podés typearlo en la firma del método. A nivel de consumidor no sabés lo posibles errores que se pueden dar. Si bien la mayoria de frameworks traen esos "error handlers", no significa que sea lo más correcto. Que bonito es leer un código explìcito y no que sea como un "goto" tirando excepciones. Las excepciones, en mi exp, se usarían más para casos realmente excepcionales que no deberian ocurrir, asi en tu metrics los loggeas y no los llenas de puros errores que sabes bien que pueden suceder, aunque esto último igual se puede omitir con excep.
@@dylangrijalva944de hecho si es lo más correcto, usar checked exceptions, ya firma tu método salvó que el lenguaje no lo permita ya es más un problema del lenguaje
Si bien Java tiene lo de especificar en la firma de la función que excepciones puede lanzar no todos los lenguajes que usan excepciones tienen esto, en TypeScript por ejemplo es muy difícil saber que lanza excepción y que no y aun mas difícil saber que específicamente que tipo de excepciones lanza, a esto en ingles le llaman hidden control flow, vas a ciegas y es posible que te enteres que una excepción existe cuando tu código ya esta en producción.
En mi opinion los errores como valores son lo mejor y creo que Rust tiene la mejor implementación , en Rust siempre vas a saber si una función retorna error y el compilador te va a obligar a que manejes el error o lo ignores de forma explicita.
Mucha gente por ejemplo se queja de que en Go hay que escribir demasiado if err != nil {}, pero no se da cuenta que si intentaran escribir el mismo código en otros lenguajes tendrían que poner try {} catch () {} por todas partes, la cosa es que en Go cuando ves la firma de la función sabes de una vez si puede haber error o no, en muchos lenguajes con excepciones no puedes saberlo.
@@germandavid2520 Algo para agregar es el tema del ?, es un shortcut para propagar en Rust, hace transformaciones a tipos escalares y todo, una maravilla.
El error handling de Rust es algo que se trabaja muy bien en general.
@@ferniexz en al caso de go así es
Rust >