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.
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.
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:
Conceptos relacionados
Depurador de flujos
Tareas relacionadas
Generación de una excepción
Diagnóstico de errores
Referencia relacionada
cciGetLastExceptionData
cciLog
cciRethrowLastException
cciThrowException
Avisos |
Marcas registradas |
Descargas |
Biblioteca |
Soporte |
Información de retorno (feedback)
![]() ![]() |
as01430_ |