Os erros internos podem ser causados por programas que armazenam dados inválidos no banco de dados ou por uma falha na lógica de um fluxo.
A estratégia mais simples para manipular erros ESQL é não fazer nada e utilizar o comportamento padrão do intermediário. O comportamento padrão é interromper o processamento da mensagem com falha e prosseguir para a próxima mensagem. Os nós de entrada e de saída fornecem opções para controlar exatamente o que acontece quando o processamento é interrompido.
Cada uma destas estratégias tem suas vantagens. O modelo transacional preserva a consistência de dados, enquanto o modelo não transacional aumenta a continuidade do processamento de mensagens. Lembre-se de que no modelo transacional a mensagem de entrada com falha é retornada à fila de entrada e o intermediário tentará processá-la novamente. O resultado mais provável disso é que a mensagem continuará falhando até que seja alcançado o limite de nova tentativa e, neste ponto, ela é colocada em uma fila de devoluções. A razão para a falha ao processar a mensagem é registrada no registro de eventos do sistema (Windows) ou no syslog (UNIX). Portanto, a mensagem com falha suspende o processamento de mensagens válidas subseqüentes por um momento e, em seguida, é deixada sem ser processada pelo intermediário.
A maioria dos bancos de dados operam de forma transacional, portanto, todas as alterações feitas em tabelas de banco de dados serão confirmadas, se o processamento da mensagem for bem-sucedido e ocorrerá o rollback se ele falhar, mantendo, assim, a integridade de dados. Uma exceção para isso é que, se o próprio intermediário ou um banco de dados falhar. (Por exemplo, a energia para as máquinas nas quais eles estão em execução pode ser interrompida). Nestes casos, é possível que as alterações em alguns bancos de dados sejam confirmadas e as alterações em outros não; ou que as alterações dos bancos de dados sejam confirmadas mas as mensagens de entrada e de saída não sejam. Se estas possibilidades são motivos de preocupação, o fluxo deverá ser coordenado e os bancos de dados envolvidos configurados para esta maneira de funcionamento.
É recomendável utilizar terminais de falha para capturar erros não manipulados. Conecte um fluxo de lógica simples ao terminal de falha. Este fluxo de lógica pode consistir em um banco de dados ou um nó Compute que grava um registro de log em um banco de dados (possivelmente incluindo o fluxo de bits da mensagem) ou grava um registro no registro de eventos. Ele também pode conter um nó de saída que grava a mensagem em uma fila especial.
A árvore de exceções completa é transmitida para qualquer nó conectado a um terminal de falha. (A árvore de exceções está descrita em Árvore Lista de Exceções).
Para obter uma discussão detalhada das opções que podem ser utilizadas para processar erros em um fluxo de mensagens, consulte Tratando Erros em Fluxos de Mensagens. Os tópicos a seguir fornecem exemplos específicos do que pode ser feito:
Para lidar com mensagens com falha, conecte um fluxo de lógica simples ao terminal de falha.
A única desvantagem desta estratégia é que, se o fluxo normal não exigir acesso a todos os campos da mensagem, o ato de forçar a análise completa da mensagem afetará o desempenho.
Se você precisar de algo melhor do que a manipulação de erro padrão, a primeira etapa será utilizar uma rotina de tratamento (consulte Instrução DECLARE HANDLER) para interceptar a exceção. A rotina de tratamento pode determinar a natureza da falha a partir do estado de SQL retornado pelo banco de dados.
No entanto, tome cuidado com este tipo de estratégia. Como a rotina de tratamento absorve a exceção, as alterações em outros bancos de dados ou gravações em filas são confirmadas.
Os erros que ocorrem nos nós de saída do MQ relatam a natureza do erro no estado SQL e fornecem informações adicionais na variável Erro nativo de SQL. Portanto, se for requerido algo melhor do que a manipulação de erro padrão, a primeira etapa será utilizar uma rotina de tratamento (consulte Instrução DECLARE HANDLER) para interceptar a exceção. Esta rotina de tratamento pode envolver bem apenas uma única instrução PROPAGATE.
Na ausência de uma restrição de tipo, uma tentativa de acesso a um campo de mensagem não existente pode resultar no valor nulo. Os valores nulos são propagados tornando o resultado nulo. Portanto, se uma expressão, ainda que complexa, não retornar um valor nulo, você saberá que todos os valores utilizados por ela para calcular seu resultado não eram nulos.
As expressões de lançamento podem ter uma cláusula padrão. Se houver uma cláusula padrão, os lançamentos falharão de maneira silenciosa; em vez de emitir uma exceção, eles apenas retornam o valor padrão. O valor padrão pode ser um número inócuo (por exemplo, zero para um inteiro) ou um valor que seja claramente inválido no contexto (por exemplo, -1 para um número de cliente). O nulo pode ser especificamente adequado, porque é um valor diferente de todos os outros e que será propagado por meio de expressões sem nenhuma possibilidade de a condição de erro estar sendo mascarada.