Manejo de errores y de excepciones

Este tema trata de cuestiones relacionadas con el manejo de errores y de excepciones que deben tenerse en cuenta al desarrollar extensiones definidas por el usuario para WebSphere Business Integration Message Broker en el lenguaje de programación C. Si va a desarrollar extensiones definidas por el usuario utilizando el lenguaje de programación Java, puede utilizar métodos de manejo de errores y de excepciones Java estándar. Si, por ejemplo, WebSphere Business Integration Message Broker emite una excepción internamente, una excepción Java de clase MbException se hace disponible.

Para que el intermediario funcione correctamente, es importante realizar el manejo de errores y excepciones correctamente. Debe conocer y comprender la manera en que la extensión definida por el usuario maneja errores y excepciones, y cuándo debe llevar a cabo esta actividad.

El intermediario de mensajes genera excepciones C++ para manejar condiciones de error. Estas excepciones se reciben en las capas de software relevantes del intermediario y se manejan según corresponda. No obstante, los programas escritos en C no pueden recibir excepciones C++ y las excepciones emitidas omitirán, por omisión, cualquier código de extensión C definido por el usuario y se recibirán en una capa superior del intermediario de mensajes.

Por convenio, las funciones de programa de utilidad suelen utilizan el valor de retorno para volver a pasar datos solicitados, como por ejemplo la dirección o el manejador de un objeto de intermediario. A veces, el valor de retorno indicará que se ha producido una anomalía. Por ejemplo, si no se ha podido recuperar la dirección o el manejador de un objeto de intermediario, se devolverá cero (CCI_NULL_ADDR). Adicionalmente, la razón para una condición de error se almacena en el parámetro de salida del código de retorno que, por convención, forma parte del prototipo de función de todas las funciones de programa de utilidad. Si la función de programa de utilidad se ha completado correctamente y el valor del parámetro returnCode no era nulo, returnCode contendrá CCI_SUCCESS. De lo contrario, contendrá uno de los códigos de retorno descritos a continuación. El valor de returnCode siempre puede comprobarse de forma segura para determinar si una función de programa de utilidad se ha completado correctamente.

Si la invocación de una función de programa de utilidad hace que el intermediario genere una excepción, ésta será visible en la extensión definida por el usuario únicamente si especificaba un valor para el parámetro returnCode de dicha función de programa de utilidad. Si se ha especificado un valor nulo para returnCode y se produce una excepción:

Esto significa que una extensión definida por el usuario no podrá realizar la recuperación de ninguno de sus 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, cciGetLastExceptionData puede utilizarse para obtener información de diagnóstico sobre el tipo de excepción ocurrida, y estos datos pueden devolverse en la estructura CCI_EXCEPTION_ST.

Si no hay ningún recurso que liberar, le recomendamos que evite establecer el argumento returnCode en la extensión definida por el usuario. El hecho de no establecer este argumento permite que las excepciones omitan las extensiones definidas por el usuario. El intermediario podrá manejar posteriormente estas excepciones en la parte superior de la pila de WebSphere Business Integration Message Broker.

Las inserciones de mensajes pueden devolverse en los miembros CCI_STRING_ST de la estructura CCI_EXCEPTION_ST. CCI_STRING_ST permite que las extensión definida por el usuario proporcione un almacenamiento intermedio para recibir las inserciones requeridas. El intermediario copiará los datos en este almacenamiento intermedio y devolverá 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 el miembro "dataLength" puede utilizarse para aumentar el tamaño del almacenamiento intermedio, si es necesario.

La extensión definida por el usuario puede realizar cualquier recuperación de errores, si procede Si se devuelve CCI_EXCEPTION, todas las excepciones deberán volver a pasarse al intermediario de mensajes para que se realice una recuperación de errores adicional. Esto se lleva a cabo invocando cciRethrowLastException, lo cual hace que la interfaz C vuelva a emitir la última excepción para que pueda manejarla otras capas del intermediario de mensajes.

Si se produce una excepción, y una extensión definida por el usuario la recibe, la extensión no debe invocar ninguna función de programa de utilidad excepto cciGetLastExceptionData o cciRethrowLastException. Si intenta invocar otras funciones de programa de utilidad, el comportamiento se hará imprevisible y puede poner en peligro la integridad del intermediario.

Si una extensión definida por el usuario encuentra un error grave, puede utilizarse cciThrowException para generar una excepción que el intermediario de mensajes procesará de la manera adecuada. La generación de dicha excepción motiva que la información suministrada se escriba en las anotaciones del sistema (syslog o Eventviewer) si no se maneja dicha excepción. La información también se escribe en el rastreo de intermediarios, si el rastreo está activo.

Tipos de excepción y comportamiento de intermediario

El intermediario genera un conjunto de excepciones que pueden notificarse a una extensión definida por el usuario. Estas excepciones también las puede generar una extensión definida por el usuario al producirse una condición de error. Las clases de excepción son:

Muy grave
Las excepciones muy graves se generan cuando se produce una condición que impide que el proceso de intermediario continúe funcionando de forma segura, o si el proceso debe terminar debido a una política del intermediario. Ejemplos de excepciones muy graves son el hecho de no adquirir un recurso de sistema fundamental, o un grave error de software recibido internamente. El intermediario procesa terminales tras recibirse una excepción muy grave.
Recuperable
Estas excepciones se generan para errores que, aunque no sean de naturaleza terminal, significan que el proceso del flujo de mensajes actual debe finalizarse. Ejemplos de excepciones recuperables son datos no válidos en el contenido de un mensaje, o el hecho de no escribir un mensaje en un nodo de salida. Al recibirse una excepción recuperable, el proceso del mensaje actual termina anormalmente en esa hebra, pero la hebra vuelve a comenzar la ejecución en el nodo de entrada correspondiente.
Configuración
Las excepciones de configuración se generan cuando una petición de configuración no se ejecuta correctamente. Esto puede deberse a un error de formato de la petición de configuración, o un error de los datos. Al emitirse una excepción de configuración, la petición es rechazada y se devuelve un mensaje de respuesta de error.
Analizador
Estas excepciones las generan los analizadores de mensajes para los errores que impiden analizar el contenido de los mensajes o crear una corriente de bits. El intermediario trata una excepción de analizador como si fuera una excepción recuperable.
Conversión
Estas excepciones las generan las funciones de conversión de caracteres del intermediario si se encuentran datos no válidos al intentar realizar la conversión a otro tipo de datos. El intermediario trata una excepción de conversión como si fuera una excepción recuperable.
Usuario
Estas excepciones se generan cuando un nodo Throw emite una excepción definida por el usuario.
Database
Estas excepciones se generan cuando un sistema de gestión de base de datos informa de un error durante la operación del intermediario. El intermediario trata una excepción de base de datos como si fuera una excepción recuperable.

Conceptos relacionados
Depurador de flujos

Tareas relacionadas
Generación de una excepción
Diagnóstico de errores

Referencia relacionada
cciGetLastExceptionData
cciLog
cciRethrowLastException
cciThrowException