Estoy usando try catch dentro del bloque try para imprimir un mensaje relativo o saber en qué método ocurrió el error.
fragmento de código
for (const searchUrl of savedSearchUrls) { console.log("here"); // function will get all the links of profiles in saved search url try { const links = await scrapeFromurl(browser, searchUrl); try { saveToDatabase(links); } catch (e) { handleError(e, "eror while saving to database"); } } catch (err) { handleError(err, "error in scrapeFromurl()"); } }He buscado en google pero no he podido encontrar un tema relacionado.
¿Cuáles son las otras formas de lograr cosas similares? cuáles son las mejores prácticas para manejar este tipo de situación.
Sugeriría usar solo un bloque de captura de prueba e instancias de error específicas para cada método, luego en el bloque de captura simplemente puede verificar qué método arroja un error usando el operador de instanceof de
class ScrapeError extends Error { message = "error in scrapeFromurl()" } class DBError extends Error { message = "eror while saving to database" } async function scrapeFromurl() { throw new ScrapeError(); } async function saveToDatabase(links) { throw new DBError(); } async function main() { try { const links = await scrapeFromurl(); await saveToDatabase(links); } catch (e) { if (e instanceof ScrapeError) { console.log('scrape', e); } if (e instanceof DBError) { console.log('dberror', e); } } } main();De forma predeterminada, un solo bloque de captura de prueba es suficiente sin necesidad de anidar otras capturas de prueba en él. Sin embargo, puede haber algunas excepciones legítimas a estas reglas.
Consideremos el siguiente ejemplo
try { myroutine(); // may throw three types of exceptions } catch (e) { if (e instanceof TypeError) { // statements to handle TypeError exceptions } else if (e instanceof RangeError) { // statements to handle RangeError exceptions } else if (e instanceof EvalError) { // statements to handle EvalError exceptions } else { // statements to handle any unspecified exceptions logMyErrors(e); // pass exception object to error handler } } Es perfectamente posible que dentro de su try haya una sección en la que un tipo de error dado, como RangeError , necesite una forma de manejo diferente a la catch principal. En este caso, podría tener sentido tener otro try-catch dentro de su intento, aunque, en este caso, para una mejor legibilidad, tendría sentido considerar el intento interno como un método y llamarlo, por lo que no anidaría físicamente el intento. -catch bloques, pero separe las preocupaciones de los try-catches en métodos separados.
Es muy posible que desee que su try-catch arroje el error aún más en la mayoría de su bloque de try , pero, en una sección específica, desea que lo maneje. Nuevamente, en este caso tendría sentido separar el try interno en su propio método.
Tener capturas de intento anidadas no es intuitivo para un lector, por lo tanto, tiene sentido separar el try interno en su propio método cada vez que encuentre la necesidad de anidar intentos. Sin embargo, como muestran los ejemplos anteriores, existen necesidades legítimas para alejarse del manejo externo de un error en algunas secciones. Sin embargo, por defecto es una buena idea considerar dichas secciones como preocupaciones separadas que vale la pena separar del método. Por supuesto, a veces es posible que desee mantener las capturas de prueba anidadas sin separar sus preocupaciones, pero la mayoría de las veces vale la pena aplicar las separaciones. Por lo tanto, una regla general que puede considerar es refactorizar los intentos de captura anidados en métodos separados o en un solo intento de captura, a menos que haya una muy buena razón para no hacerlo .
En scripts asincrónicos, puede usar dominios para el manejo de errores. Y trycatch en trycatch puede tratarse como dominio en dominio, lo cual no tiene sentido. Además, los programadores siempre tienden a evitar que el código crezca horizontalmente de esta manera.
{ ... { ... { ... (and so on) { } } } }Así que es una muy mala idea. Puedo seguir contando los inconvenientes de este enfoque, pero no lo haré. Solo use un trycatch con switchcase adentro para manejar todos los errores