Este tópico lida com questões relativas ao tratamento de erros e exceções que você deve considerar ao desenvolver extensões definidas pelo usuário para o WebSphere Message Broker na linguagem de programação C.Se você estiver desenvolvendo extensões definidas pelo usuário utilizando a linguagem de programação Java, você pode utilizar métodos padrão Java de tratamento de erros e exceções. Se, por exemplo, WebSphere Message Broker lançar uma exceção internamente, uma exceção Java da classe MbException será disponibilizada.
O tratamento correto de erros e exceções é importante para a operação correta do intermediário. Você deve estar ciente e compreender como e quando sua extensão definida pelo usuário precisa tratar erros e exceções.
O intermediário de mensagem gera exceções C++ para tratar de condições de erro. Essas exceções são capturadas nas camadas relevantes de software no intermediário e tratadas de acordo. Entretanto, programas escritos em C não podem capturar exceções C++ e quaisquer exceções lançadas ignorarão, por padrão, qualquer código de extensão C definido pelo usuário e serão capturados em uma camada mais alta do intermediário de mensagem.
Funções de utilitário, por convenção, normalmente utilizam o valor de retorno para transmitir de volta os dados solicitados; por exemplo, o endereço ou manipulação de um objeto do intermediário. O valor de retorno às vezes indica que ocorreu uma falha. Por exemplo, se o endereço ou identificador de um objeto do intermediário não pôde ser recuperado, zero (CCI_NULL_ADDR) será retornado. Além disso, a razão para uma condição de erro é armazenada no parâmetro de saída do código de retorno, o qual é, por convenção, parte do protótipo de função de todas as funções de utilitário. Se a função de utilitário foi concluída com sucesso e returnCode não for nulo, returnCode conterá CCI_SUCCESS. Caso contrário, ele conterá um dos códigos de retorno descritos adiante. O valor de returnCode sempre pode ser testado com segurança para determinar se uma função de utilitário foi bem-sucedida.
Isso significa que uma extensão definida pelo usuário seria incapaz de executar qualquer recuperação de seus próprios erros. Se, no entanto, returnCode estiver especificado e ocorrer uma exceção, será retornado um código de retorno de CCI_EXCEPTION. Neste caso, cciGetLastExceptionData ou cciGetLastExceptionDataW (a diferença existente que cciGetLastExceptionDataW retorna uma CCI_EXCEPTION_WIDE_ST que pode conter o texto de rastreio Unicode) pode ser utilizado para obter informações de diagnóstico sobre o tipo de exceção que ocorreu. Os dados são retornados na estrutura CCI_EXCEPTION_ST ou CCI_EXCEPTION_WIDE_ST.
Se não houver recursos a serem liberados, você não deve configurar o argumento returnCode na extensão definida pelo usuário. A não-configuração desse argumento permite que as exceções ignorem as extensões definidas pelo usuário. Essas exceções então podem ser tratadas em um nível mais alto da pilha WebSphere Message Broker pelo intermediário.
Inserções de mensagens podem ser retornadas nos membros CCI_STRING_ST da estrutura CCI_EXCEPTION_ST. CCI_STRING_ST permite que a extensão definida pelo usuário forneça um buffer para receber quaisquer inserções necessárias. O intermediário copia os dados nesse buffer e retorna o número de saída de bytes e o comprimento real dos dados. Se o buffer não for grande o suficiente, nenhum dado será copiado e o membro "dataLength" poderá ser utilizado para aumentar o tamanho do buffer, se necessário.
A extensão definida pelo usuário pode executar sua própria recuperação de erro,
se requerido, configurando um valor não-nulo para returnCode.
As chamadas da função de utilitário retornam para a extensão definida pelo usuário e transmitem seu status através de returnCode. Todas as exceções que ocorrem em uma função de utilitário devem ser transmitidas de volta para o intermediário de mensagem para que a recuperação de erro adicional seja executada, ou seja, quando CCI_EXCEPTION for retornada no returnCode.
Isso é feito chamando cciRethrowLastException,
após a extensão definida pelo usuário ter concluído seu próprio processamento de erro. A chamada de cciRethrowLastException faz com que a interface C emita
novamente a última exceção para que ela possa ser manipulada por outras camadas no
intermediário de mensagem. Observe que, assim como uma chamada exit C,
cciRethrowLastException não retorna
nesse caso.
Se uma exceção ocorrer e for capturada por uma extensão definida pelo usuário, a extensão não deverá chamar nenhuma função de utilitário, exceto cciGetLastExceptionData, cciGetLastExceptionDataW ou cciRethrowLastException. Uma tentativa de chamar outras funções de utilitário resulta em um comportamento imprevisível que pode comprometer a integridade do intermediário.
Se uma extensão definida pelo usuário encontrar um erro grave, cciThrowException ou cciThrowExceptionWpode ser utilizada para gerar uma exceção processada pelo intermediário de mensagens da maneira correta. A geração de uma exceção desse tipo faz com que as informações fornecidas sejam gravadas no log de sistema (syslog ou Eventviewer) se a exceção não for manipulada. As informações também são gravadas no Intermediário se o rastreio estiver ativo.
O intermediário gera um conjunto de exceções que pode ser transmitido a uma extensão definida pelo usuário. Essas exceções também podem ser geradas por uma extensão definida pelo usuário quando uma condição de erro for encontrada. As classes de exceção são: