Manejo de errores y excepciones

En esta sección se describen temas relacionados con el manejo de errores y excepciones que debe tener en cuenta cuando desarrolla extensiones definidas por el usuario para WebSphere Message Broker en el lenguaje de programación C. Si está desarrollando extensiones definidas por el usuario utilizando el lenguaje de programación C, puede utilizar métodos de manejo de errores y excepciones Java estándar. Si, por ejemplo, WebSphere Message Broker genera una excepción internamente, hay una excepción Java de clase MbException disponible.

El manejo correcto de errores y excepciones es importante para que el intermediario funcione correctamente. Debe tener en cuenta esto y comprender cómo y cuándo la extensión definida por el usuario necesita manejar errores y excepciones.

El intermediario de mensajes genera excepciones C++ para manejar condiciones de error. Estas excepciones se captan en las capas de software relevantes del intermediario y se manejan en consecuencia. No obstante, los programas escritos en C no capturan las excepciones de C++ y cualquier excepción que se genere ignorará, por omisión, el código de extensión definido por el usuario en C y se capturará en una capa superior del intermediario de mensajes.

Por convenio, generalmente las funciones de programa de utilidad suelen utilizar el valor de retorno para devolver los datos solicitados; por ejemplo, la dirección o el manejador de un objeto de intermediario. A veces, el valor de retorno indica que se ha producido un error. Por ejemplo, si no se ha podido recuperar la dirección o el manejador de un objeto del intermediario, entonces 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 del programa de utilidad. Si la función del programa 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 a continuación. El valor de returnCode siempre se puede comprobar con seguridad para determinar si una función del programa de utilidad se ha ejecutado correctamente.

Si la invocación de una función del programa de utilidad hace que el intermediario genere una excepción, ésta sólo será visible para la extensión definida por el usuario si se ha especificado un valor para el parámetro returnCode correspondiente a dicha función del 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 ninguna de sus acciones de recuperación de errores propia. 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 un CCI_EXCEPTION_WIDE_ST que puede contener texto de rastreo Unicode) para obtener información de diagnóstico acerca del 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 recursos para liberar, debería evitar establecer el argumento returnCode en la extensión definida por el usuario. Si no establece este argumento, las excepciones podrán ignorar las extensiones definidas por el usuario. A continuación, el intermediario puede manejar estas excepciones a niveles más altos de la pila WebSphere Message Broker.

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 cualquier inserción necesaria. El intermediario 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 copian los datos y se puede utilizar el miembro "dataLength" para aumentar el tamaño del almacenamiento intermedio, si es necesario.

Inicio del cambioLa extensión definida por el usuario puede llevar a cabo su propia recuperación de errores, si es necesario, estableciendo un valor que no sea nulo para returnCode. Las llamadas a la función del programa de utilidad devuelven el control a la extensión definida por el usuario y le pasan su estado mediante returnCode. Todas las excepciones que se producen en una función del programa de utilidad se deben devolver al intermediario de mensajes para llevar a cabo una recuperación adicional de errores, es decir, cuando se devuelve CCI_EXCEPTION en returnCode. Para ello, se invoca a cciRethrowLastException después de que la extensión definida por el usuario haya completado su propio proceso de errores. Al llamar a cciRethrowLastException, la interfaz C vuelve a generar la última excepción de modo que puedan manejarla otras capas del intermediario de mensajes. Observe que, de forma parecida a la llamada exit de C, cciRethrowLastException no devuelve el control en este caso.Fin del cambio

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

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

Tipos de excepciones y comportamiento del intermediario

El intermediario 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 de error que impide que el proceso del intermediario continúe ejecutándose con seguridad o cuando la política del intermediario 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 intermediario termina después de generar una excepción fatal.
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 aborta en dicha hebra pero se vuelve a iniciar la ejecución de la hebra en su nodo de entrada.
Configuración
Las excepciones de configuración se generan cuando falla una petición de configuración. Esto puede ser debido a un error del formato de la petición de configuración o a un error de los datos. Cuando se genera una excepción de configuración, se rechaza la petición 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 del mensaje o crear una corriente de bits. El intermediario trata una excepción del analizador como 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 durante la conversión a otro tipo de datos. El intermediario trata una excepción de conversión como una excepción recuperable.
Usuario
Estas excepciones se generan cuando un nodo Throw genera una excepción definida por el usuario.
Base de datos
Estas excepciones se generan cuando un sistema de gestión de base de datos informa acerca de un error durante la ejecución del intermediario. El intermediario trata una excepción de base de datos como una excepción recuperable.
Conceptos relacionados
Depurador de flujos de mensajes
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
as01430_