En esta función que maneja una llamada API REST, cualquiera de las funciones llamadas para manejar partes de la solicitud puede generar un error para indicar que se debe enviar un código de error como respuesta. Sin embargo, la función en sí también podría descubrir un error, momento en el que debería saltar al bloque de manejo de excepciones.
static async handleRequest(req) { try { let isAllowed = await checkIfIsAllowed(req); if (!isAllowed) { throw new ForbiddenException("You're not allowed to do that."); } let result = await doSomething(req); // can also raise exceptions sendResult(result); } catch(err) { sendErrorCode(err); } } Webstorm subrayará el throw con el siguiente mensaje: 'throw' of exception caught locally. This inspection reports any instances of JavaScript throw statements whose exceptions are always caught by containing try statements. Using throw statements as a "goto" to change the local flow of control is likely to be confusing.
Sin embargo, no estoy seguro de cómo refactorizar el código para mejorar la situación.
Podría copiar y pegar el código del bloque catch en el control if , pero creo que esto haría que mi código fuera menos legible y más difícil de mantener.
Podría escribir una nueva función que realice la verificación isAllowed y genere una excepción si no tiene éxito, pero eso parece estar eludiendo el problema, en lugar de solucionar un problema de diseño que supuestamente informa Webstorm.
¿Estamos usando las excepciones de manera incorrecta y por eso nos encontramos con este problema, o el error de Webstorm simplemente es confuso y debe desactivarse?
Está comprobando algo y lanzando una excepción si isAllowed falla, pero sabe qué hacer en esa situación: llame a sendErrorCode . Debe lanzar excepciones a las llamadas externas si no sabe cómo manejar la situación, es decir, en circunstancias excepcionales.
En este caso, ya tiene un proceso definido de qué hacer si esto sucede, solo utilícelo directamente sin el lanzamiento/atrapa indirecto:
static async handleRequest(req) { try { let isAllowed = await checkIfIsAllowed(req); if (!isAllowed) { sendErrorCode("You're not allowed to do that."); return; } let result = await doSomething(req); // can also raise exceptions sendResult(result); } catch(err) { sendErrorCode(err); } }Podría copiar y pegar el código del bloque
catchen el controlif, pero creo que esto haría que mi código fuera menos legible y más difícil de mantener.
Por el contrario, como se indicó anteriormente, esperaría que esta sea la forma de manejar esta situación.
Contrariamente a la opinión de James Thorpe, prefiero ligeramente el patrón de lanzamiento. No veo ninguna razón convincente para tratar los errores locales en el bloque de prueba de manera diferente a los errores que surgen desde más abajo en la pila de llamadas... simplemente arrójelos. En mi opinión, esta es una mejor aplicación de la coherencia.
Debido a que este patrón es más consistente, naturalmente se presta mejor a la refactorización cuando desea extraer la lógica en el bloque de prueba a otra función que quizás esté en otro módulo/archivo.
// main.js try { if (!data) throw Error('missing data') } catch (error) { handleError(error) } // Refactor... // validate.js function checkData(data) { if (!data) throw Error('missing data') } // main.js try { checkData(data) } catch (error) { handleError(error) }Si en lugar de lanzar el bloque de prueba maneja el error, entonces la lógica tiene que cambiar si lo refactoriza fuera del bloque de prueba.
Además, manejar el error tiene la desventaja de recordar regresar temprano para que el bloque de prueba no continúe ejecutando la lógica después de que se encuentre el error. Esto puede ser bastante fácil de olvidar.
try { if (!data) { handleError(error) return // if you forget this, you might execute code you didn't mean to. this isn't a problem with throw. } // more logic down here } catch (error) { handleError(error) }Si le preocupa qué método es más eficaz, no debería estarlo. Manejar el error es técnicamente más eficaz, pero la diferencia entre los dos es absolutamente trivial.
Considere la posibilidad de que WebStorm sea demasiado obstinado aquí. ESLint ni siquiera tiene una regla para esto. Cualquier patrón es completamente válido.
Dado que esto no es un error de bloqueo, sino solo una recomendación del IDE, la pregunta debe verse desde dos lados.
El primer lado es el rendimiento. Si esto es un cuello de botella y es potencialmente posible usarlo con la compilación o al transferir a versiones nuevas (aún no lanzadas) de nodejs, la presencia de repeticiones no siempre es una mala solución. Parece que el IDE apunta precisamente en este caso y que tal diseño puede conducir a una mala optimización en algunos casos.
El segundo lado es el diseño del código. Si hace que el código sea más legible y simplifica el trabajo para otros desarrolladores, consérvelo. Desde este punto de vista, ya se han propuesto soluciones anteriormente.