Manipulación de Excepciones como instrumento para el tratamiento de errores

El manejo correcto de errores y excepciones es importante para que el nodo de integración funcione correctamente. Debe considerar cómo y cuándo la extensión definida por el usuario debe manejar errores y excepciones.

El manejo de errores y excepciones de este tema describe factores que debe tener en cuenta cuando desarrolle extensiones definidas por el usuario para IBM® Integration Bus en el lenguaje de programación C. Si está desarrollando extensiones definidas por el usuario utilizando el lenguaje de programación Java™, puede utilizar métodos de manejo de errores y excepciones Java estándar. Si, por ejemplo, IBM Integration Bus genera una excepción internamente, hay una excepción Java de clase MbExceptiondisponible.

El nodo de integración genera excepciones de C++ para manejar condiciones de error. Estas excepciones se detectan en las capas de software relevantes del nodo de integración y se manejan en consecuencia. No obstante, los programas escritos en C no pueden detectar excepciones de C++, y todas las excepciones que se generan pasan por alto, de forma predeterminada, todo el código de extensiones definidas por el usuario en C y se detectan en una capa superior del nodo de integración.

Por convenio, las funciones de utilidad normalmente utilizan el valor de retorno para devolver los datos solicitados; por ejemplo, la dirección o el manejador de un objeto de nodo de integración. A veces, el valor de retorno indica que se ha producido un error. Por ejemplo, si la dirección o el manejador de un objeto de nodo de integración no se ha podido recuperar, se devuelve cero (CCI_NULL_ADDR). Adicionalmente, el motivo de una condición de error se almacena en el parámetro de salida del código de retorno que, por convenio, forma parte del prototipo de función de todas las funciones de utilidad. Si la función de utilidad se ha completado correctamente y el valor de returnCode no es nulo, returnCode contiene CCI_SUCCESS. De lo contrario, contiene uno de los códigos de retorno que se describen aquí. Puede comprobar el valor de returnCode para determinar si una función de utilidad se ha realizado correctamente.

Si la llamada a una función de utilidad hace que el nodo de integración genere una excepción, el error es visible para la extensión definida por el usuario sólo si especificaba un valor para el parámetro returnCode correspondiente a dicha función de utilidad. Si se especificó un valor nulo para returnCode y se produce una excepción:

• La extensión definida por el usuario no reconoce dicha excepción
• La función de utilidad no vuelve a la extensión definida por el usuario
• El control de la ejecución pasa a las capas superiores de la pila del nodo de integración para procesar la excepción

Por lo tanto, una extensión definida por el usuario no puede realizar su propia recuperación de errores. No obstante, si se especifica el parámetro returnCode y se produce una excepción, se devuelve un código de retorno de CCI_EXCEPTION. En este caso, se puede utilizar cciGetLastExceptionData o cciGetLastExceptionDataW (siendo la diferencia que cciGetLastExceptionDataW devuelve una estructura CCI_EXCEPTION_WIDE_ST que puede contener texto de rastreo Unicode) para obtener información de diagnóstico sobre el tipo de excepción que se ha producido. Los datos se devuelven en la estructura CCI_EXCEPTION_ST o CCI_EXCEPTION_WIDE_ST.

Si no hay ningún recurso para liberar, no establezca el argumento returnCode en la extensión definida por el usuario. Si no establece este argumento, las excepciones pueden ignorar las extensiones definidas por el usuario. A continuación, el nodo de integración puede manejar estas excepciones a niveles más altos de la pila IBM Integration Bus.

Se pueden devolver inserciones de mensajes en los miembros CCI_STRING_ST de la estructura CCI_EXCEPTION_ST. CCI_STRING_ST permite que la extensión definida por el usuario proporcione un almacenamiento intermedio para recibir todas las inserciones necesarias. El nodo de integración copia los datos en este almacenamiento intermedio y devuelve el número de bytes de salida y la longitud real de los datos. Si el almacenamiento intermedio no es lo suficientemente grande, no se copia ningún dato y se puede utilizar el miembro "dataLength" para aumentar el tamaño del almacenamiento intermedio, si es necesario.

La extensión definida por el usuario puede establecer un valor no nulo para returnCode y proporcionar su propia recuperación de errores, si fuera necesario. Las llamadas a la función de utilidad vuelven a la extensión definida por el usuario y pasan su estado mediante returnCode. Todas las excepciones que se producen en una función de utilidad se deben devolver al nodo de integración para llevar a cabo una recuperación adicional de errores; es decir, cuando se devuelve CCI_EXCEPTION en returnCode. Para ello, se llama a cciRethrowLastException después de que la extensión definida por el usuario ha completado su propio proceso de errores. La llamada a cciRethrowLastException hace que la interfaz C vuelva a generar la última excepción para que puedan manejarla otras capas del nodo de integración. De la misma manera que la llamada exit de C, cciRethrowLastException no regresa en este caso.

Si se produce una excepción y es detectada por una extensión definida por el usuario, la extensión no debe llamar a funciones de utilidad, excepto a cciGetLastExceptionData, cciGetLastExceptionDataW o cciRethrowLastException. Si se intenta llamar a otras funciones de utilidad, el comportamiento puede ser imprevisible y puede llegar a comprometer la integridad del nodo de integración.

Si una extensión definida por el usuario encuentra un error grave, se puede utilizar cciThrowException o cciThrowExceptionW para generar una excepción que el nodo de integración procese de manera correcta. Si se genera una excepción de este tipo, la información suministrada se graba en las anotaciones cronológicas del sistema (syslog o Eventviewer) si no se maneja la excepción. La información también se graba en el rastreo (si el rastreo está activo.

Tipos de excepciones y comportamiento del nodo de integración

El nodo de integración genera un conjunto de excepciones que pueden pasarse a una extensión definida por el usuario. Estas excepciones también las puede generar una extensión definida por el usuario cuando se encuentra una condición de error. Las clases de excepción son:

Fatal

Las excepciones fatales se generan cuando se produce una condición que impide que el proceso del nodo de integración continúe ejecutándose de forma segura o cuando la política del nodo de integración requiere la finalización del proceso. Como ejemplos de excepciones fatales están la imposibilidad de adquirir un recurso crítico del sistema o un error de software grave capturado internamente. El proceso del nodo de integración termina después de generar una excepción fatal. Se anotan las excepciones muy graves.

Recuperable

Estas excepciones se generan para errores que, aunque no son terminales por naturaleza, significan que debe finalizase el proceso del flujo de mensajes actual. Por ejemplo, las excepciones recuperables son datos no válidos en el contenido de un mensaje o un error de grabación de un mensaje en un nodo de salida. Cuando se genera una excepción recuperable, el proceso del mensaje actual se cancela en dicha hebra pero se vuelve a iniciar la ejecución de la hebra en su nodo de entrada. Las excepciones recuperables no se anotan.

Configuración

Las excepciones de configuración se generan cuando falla una solicitud de configuración. Esto puede ser debido a un error del formato de la solicitud de configuración o a un error de los datos. Cuando se genera una excepción de configuración, se rechaza la solicitud y se devuelve un mensaje de respuesta de error. No se anotan las excepciones de configuración.

Analizador

Estas excepciones las generan los analizadores de mensajes para los errores que impiden analizar el contenido del mensaje o crear una corriente de bits. El nodo de integración trata una excepción del analizador como una excepción recuperable. Generalmente, las excepciones de analizador se anotan, a menos que se consideren excepciones recuperables.

Conversión

Estas excepciones las generan las funciones de conversión de caracteres del nodo de integración si se encuentran datos no válidos al intentar la conversión a otro tipo de datos. El nodo de integración trata una excepción de conversión como una excepción recuperable y, por tanto, no se anota.

Usuario

Estas excepciones se generan cuando un nodo Throw genera una excepción definida por el usuario. Las excepciones de usuario se anotan.

Base de datos

Estas excepciones se generan cuando un sistema de gestión de bases de datos informa de un error durante la operación del nodo de integración. El nodo de integración trata una excepción de base de datos como una excepción recuperable. Las excepciones de base de datos se anotan si han generado una condición muy grave.

Fuente:https://www.ibm.com/support/knowledgecenter/es/SSMKHH_10.0.0/com.ibm.etools.mft.doc/as01430_.htm