Recientemente me encontraba desarrollando una funcionalidad la cual se encarga de subir archivos a la nube en Node 14, un proceso “sencillo” entre comillas, el reto era principalmente una validación a una url devuelta por la funcionalidad de subir archivos, a este había que hacer un get y “atrapar” el estatus que tenga, un 200 en caso ok o un 400 en un caso error. El flujo podría ser algo como esto:...
Hace un par de proyectos atrás, me tocó refactorizar una aplicación hecha en ionic v3, la versión novedosa (En aquel tiempo) en utilizar un webview para generar una app móvil con angular y typescript al nivel más arriba. Parte del motivo de la refactorización y reconstrucción de algunos componentes, era que algunos no funcionaban como se esperaba, errores básicos por falta de pruebas de parte de las personas que mantenían el proyecto mucho antes de mi equipo....
Al desarrollar un microservicio simple en hapijs, me di cuenta que al siempre utilizar async/await casi era obligado en ciertos escenarios utilizar try/catch (Definido así desde arquitectura inicial del proyecto), lo cual no me tenía del todo convencido y recien empezando con Go me di cuenta que no manejan este tipo de excepciones por los siguientes principios. Usar excepciones para errores esperados es una complejidad básicamente innecesaria. Además, mucha gente ha notado que mover el manejo de errores lejos del origen del error hace que las personas no piensen en las rutas de error....