Después de que el programa Python informa un error, ¿hay alguna buena manera de iniciarlo de nuevo además de intentarlo?
¡Maneja sólo las excepciones que deberían ser manejadas! ¡Vuelva a intentar únicamente el proceso que se pueda volver a intentar! No agregue try... excepto... casualmente. Capturar sin consideración solo traerá problemas a su propio proceso de depuración.
No todas las excepciones pueden ser manejadas por usted. Para muchas excepciones, debe enviarlas a la persona que llama. Si detecta una excepción y no la descarta, le está diciendo a la persona que llama que el proceso anterior ya lo hizo. falló Puede continuar resolviendo problemas, pero si ocurre un problema, continuar haciéndolo a menudo tendrá consecuencias más graves, que generalmente son peores que abortar todo el proceso mediante una excepción. Estas excepciones generalmente finalmente se envían al usuario que ejecuta el programa, o se registran en el registro a través del marco del servicio o se devuelven a la persona que llama remotamente, de modo que al ver esta excepción tendrá pistas para encontrar el problema. Solo puede hacer esto si está seguro de que detectar esta excepción no tendrá consecuencias más graves y, si no es una excepción normal, asegúrese de escribir esta excepción en el registro para proporcionar pistas para encontrar el problema.
No se pueden reintentar todos los procesos. Si reintenta muchos procesos una vez, todo el proceso se interrumpirá por completo. Por ejemplo, se produce una excepción de red al llamar a la interfaz web. ya se ha ejecutado, o puede que no se ejecute correctamente. La mayoría de las API no son idempotentes cuando se diseñan nuevamente. Si lo intenta nuevamente, se realizará la operación correspondiente. Por ejemplo, si su operación es transferir 100 yuanes. Nuevamente se realizarán más transferencias por 100 yuanes. Si desea introducir un mecanismo de reintento fallido, debe asegurarse de que el proceso sea idempotente en el diseño del proceso. Idempotencia significa que ejecutar el mismo proceso varias veces no provocará resultados anormales. En realidad, hay muchos detalles involucrados en este requisito de diseño y no es tan fácil de cumplir, por lo que normalmente me opongo a este tipo de código que lo vuelve a intentar tres veces sin pensar.
Este principio también se puede extender al uso de herramientas externas como supervisord para reiniciar automáticamente los servicios. En realidad, este es un problema que debe tenerse en cuenta:
Si su programa es completamente normal, no debería ser anormal. Salir;
Si sale de manera anormal y no sabe qué sucedió, ¿cómo sabe que debe reiniciar inmediatamente?
¿Qué debo hacer si se cierra de forma anormal después de reiniciar?
Por ejemplo, cuando algunos programas fallan, pueden generar archivos de volcado y escribir una gran cantidad de registros de excepciones. En este caso, si se reinician automáticamente sin consideración, continuarán escribiendo registros o generando volcados. puede llenar rápidamente el disco, provocando que otros servicios e incluso todo el servidor se vuelvan anormales. Para otro ejemplo, algunos programas llamarán a servicios externos cuando se inicien. El proceso de inicialización puede ejercer presión sobre los servicios externos. Las excepciones repetidas y las inicializaciones repetidas pueden hacer que todo el servicio externo no esté disponible. Estas posibles consecuencias requieren un análisis y una discusión cuidadosos, por lo que algunas herramientas que admiten las funciones correspondientes tendrán algunas configuraciones, como cuánto tiempo se ejecutarán después de reiniciar antes de reiniciar, que deben configurarse cuidadosamente.
Si no puede presentar un argumento suficiente para demostrar que estas estrategias de reintento automático y reinicio automático no causarán otros problemas, le recomiendo que adopte una estrategia más conservadora y solo utilice el monitoreo para detectar si el servicio está disponible. El procesamiento de alarmas manual se utiliza para resolver posibles fallas anormales del servicio. Si su servicio es lo suficientemente estable, esto no causará mucha presión de operación y mantenimiento. Si el servicio no es lo suficientemente estable, primero debe mejorar la estabilidad. servicio.
MANTÉNLO SIMPLE Y ESTÚPIDO, NO SEAS DEMASIADO INTELIGENTE