Gestionando excepciones en Indy TIdTCPServer y TIdTCPClient
Gestión de excepciones en Indy TIdTCPServer y TIdTCPClient
He leído en otros mensajes de este foro y en otros lugares que en los componentes de Indy las excepciones (descendientes de EIdException) se gestionan internamente.
Por esta razón, en el método Execute de TCPServer no es necesario utilizar un bloque try-catch.
Pero, ¿qué sucede si en el método Execute de TCPServer ocurre otro tipo de excepción?
En mi aplicación de servidor, he puesto un componente TIdTCPServer en el formulario principal. Si ocurre algo malo dentro de su método Execute y no lo gestiono, el servidor se detiene.
Obviamente, necesito que el servidor esté en funcionamiento, por lo que utilizo un bloque try-catch y, si hay una excepción (cualquier tipo de excepción), reinicio el servidor.
No sé si esto es lo mejor que se puede hacer.
A veces, con la aplicación del servidor en ejecución en el IDE, obtengo el error:
ninguno
El proyecto CallMonitor.exe generó una excepción de clase EIdSocketError con el mensaje ‘Error de socket #10054 – Conexión restablecida por el par.’.
Probablemente causado por el cliente que se ejecuta en la misma computadora (no en el IDE).
La ejecución de la aplicación está bloqueada y si detengo la ejecución (break), el código se detiene en el archivo IdStack donde se encuentra la gran ¡LEEME!!! acerca de la excepción 10038.
Presiono F9 y la aplicación continúa ejecutándose.
Para mí no está muy claro qué sucede. ¿Es efectivo mi bloque try-catch en esta situación? ¿O es inútil o perjudicial?
¿Debo filtrar las excepciones de Indy y otras excepciones?
En el lado del cliente, en mi aplicación hay un objeto TIdTCPClient en el formulario principal y la conexión al servidor se gestiona en el hilo principal. Luego hay otro hilo para gestionar la comunicación con el servidor. En el método Execute del hilo de comunicación, tengo un bloque try-catch y un bucle en el cual envío una solicitud al servidor cada 2 segundos o cuando el usuario solicita datos y decodifico la respuesta del servidor.
Si hay una excepción EIdReadTimeout, termino el hilo y lo reinicio. Para otras excepciones, termino el hilo, desconecto/conecto el TIdTCPClient y reinicio el hilo.
Creo que esta es una situación diferente porque en el servidor la excepción se gestionó dentro del hilo TIdTCPServer, mientras que en el cliente la excepción se gestiona en un hilo que simplemente utiliza el TCPClient->Socket para comunicarse con el servidor, ¿verdad?
Se agradece cualquier respuesta/commentario/sugerencia.
davy.ai
En los componentes de Indy, las excepciones descendientes de
EIdExceptionson gestionadas internamente. Por lo tanto, en el métodoExecutedeTCPServer, no es necesario utilizar un bloquetry-catchpara gestionar estas excepciones. Sin embargo, si ocurre otro tipo de excepción, el servidor puede detenerse y puede ser necesario utilizar un bloquetry-catchpara manejarla.Si la aplicación del servidor está en ejecución y ocurre una excepción no controlada, el servidor puede detenerse. Para evitar esto, se puede utilizar un bloque
try-catchpara capturar cualquier excepción, no solo excepciones de Indy. Si se captura una excepción, el servidor puede reiniciarse.En el caso de la excepción
EIdSocketError, que puede ocurrir si un cliente se desconecta abruptamente, un bloquetry-catchpuede no ser efectivo para evitar que el servidor se detenga. Sin embargo, puede ser útil capturar y registrar la excepción para ayudar a diagnosticar la causa del problema.En el lado del cliente, como se utiliza un hilo de comunicación separado, se puede utilizar un bloque
try-catchen el métodoExecutedel hilo para gestionar las excepciones que puedan ocurrir durante la comunicación con el servidor. En el caso de la excepciónEIdReadTimeout, el hilo puede terminarse y reiniciarse. Para otras excepciones, el hilo puede terminarse y elTIdTCPClientpuede desconectarse y volver a conectarse antes de reiniciar el hilo.En resumen, gestionar las excepciones en los componentes de Indy puede ser complicado y puede ser necesario utilizar bloques
try-catchpara manejar excepciones que no descienden deEIdException. También puede ser útil capturar y registrar excepciones para ayudar a diagnosticar problemas.