Tratamento de Erros e Exceções

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 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, 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 utilitárias, por convenção, normalmente utilizam o valor de retorno para transmitir de volta os dados pedidos, por exemplo, o endereço ou identificador de um objeto do intermediário. O valor de retorno às vezes indicará 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 utilitárias. Se a função utilitária foi concluída com sucesso e returnCode não for nulo, returnCode irá 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.

Se a chamada de uma função utilitária fizer o intermediário gerar uma exceção, isso será visível para a extensão definida pelo usuário somente se ela especificou um valor para o parâmetro returnCode para essa função utilitária. Se um valor nulo tiver sido especificado parareturnCode, ocorrerá uma exceção:

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 pode ser utilizado para obter informações de diagnóstico sobre o tipo de exceção que ocorreu, retornando esses dados na estrutura CCI_EXCEPTION_ST.

Se não houver recursos a serem liberados, recomenda-se evitar definir o argumento returnCode na extensão definida pelo usuário. A não-definição desse argumento permitirá que as exceções ignorem as exceções definidas pelo usuário. Essas exceções então podem ser tratadas em um nível mais alto da pilha 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 copiará os dados para esse buffer e retornará o número de bytes que saíram 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 qualquer recuperação de erro, se necessário. Se CCI_EXCEPTION for retornado, todas as exceções precisam ser transmitidas de volta ao intermediário de mensagem para que seja executada recuperação de erro adicional. Isto pode ser feito chamando cciRethrowLastException, o que faz com que a interface C emita novamente a última exceção para que ela possa ser tratada por outras camadas no intermediário de mensagem.

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 utilitária exceto cciGetLastExceptionData ou cciRethrowLastException. Uma tentativa de chamar outras funções utilitárias resultará em comportamento imprevisível, o que pode comprometer a integridade do intermediário.

Se uma extensão definida pelo usuário encontrar um erro grave, cciThrowException pode 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.

Tipos de Exceção e Comportamento do Intermediário

O intermediário gera um conjunto de exceções que pode ser aconselhado 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:

Fatal
Exceções fatais são geradas quando ocorre uma condição que impede que o processo do intermediário continue a execução com segurança, ou onde seja critério do intermediário finalizar o processo. Exemplos de exceções fatais são, falha para conseguir adquirir um recurso crítico do sistema ou um erro grave de software capturado internamente. O processo do intermediário é finalizado após o lançamento de uma exceção fatal.
Recuperável
Estas são geradas para erros que, embora não terminais por natureza, significam que o processamento do fluxo de mensagens atual precisa ser encerrado. Exemplos de exceções recuperáveis são dados inválidos no conteúdo de uma mensagem ou falha para conseguir gravar uma mensagem em um nó de saída. Quando uma exceção recuperável é lançada, o processamento da mensagem atual é interrompido nesse encadeamento, mas o encadeamento recomeça a execução em seu nó de entrada.
Configuração
Exceções de configuração são geradas quando um pedido de configuração falha. Isso pode ocorrer devido a um erro no formato do pedido de configuração ou a um erro nos dados. Quando uma exceção de configuração é lançada, o pedido é rejeitado e uma mensagem de resposta de erro é retornada.
Analisador
Estas são geradas por analisadores de mensagem para erros que impedem a análise do conteúdo da mensagem ou a criação de um fluxo de bits. Uma exceção de analisador é tratada como uma exceção recuperável pelo intermediário.
Conversão
Estas são geradas pelas funções de conversão de caracteres do intermediário se dados inválidos forem encontrados ao tentar converter para outro tipo de dados. Uma exceção de conversão é tratada como uma exceção recuperável pelo intermediário.
Usuário
Estas são geradas quando um nó Throw lança uma exceção definida pelo usuário.
Banco de Dados
Estas são geradas quando um sistema de gerenciamento de banco de dados relata um erro durante a operação do intermediário. Uma exceção de banco de dados é tratada como uma exceção recuperável pelo intermediário.

Conceitos relacionados
Depurador de Fluxo

Tarefas relacionadas
Lançando uma Exceção
Diagnosticando Erros

Referências relacionadas
cciGetLastExceptionData
cciLog
cciRethrowLastException
cciThrowException