Guia de tratamento de erros para desenvolvedores Java

Guia de tratamento de erros para desenvolvedores Java

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br

[ad_1]

Tempo de leitura: 13 minutos

Os manipuladores de erros MuleSoft são ferramentas poderosas para garantir que seus programas possam se recuperar facilmente de eventos inesperados. Esta postagem explica essas ferramentas específicas para tratamento de erros Java, para ajudar os desenvolvedores Java a compreender rapidamente os conceitos de tratamento de erros MuleSoft.

Embora as poderosas ferramentas de tratamento de erros da MuleSoft possam ser difíceis de entender no início, os conceitos por trás delas são semelhantes aos de outras linguagens de programação orientadas a objetos. Nesta postagem, veremos os elementos individuais do pacote de tratamento de erros da MuleSoft. Para cada um, descreveremos sua funcionalidade em termos deste exemplo de código Java:

Neste exemplo inventado, o código Java aceita duas Strings e tenta convertê-las em inteiros. Se esta conversão falhar, o código lança uma NumberFormatException, que deve ser tratada na parte superior da pilha de chamadas. Caso contrário, a divisão inteira é tentada e o resultado é retornado. No caso de divisão por zero, o código pega uma ArithmeticException e retorna “infinito”, como se a operação tivesse sido concluída com êxito.

Veremos o caso ‘lança’ e o caso ‘captura’ separadamente, e construiremos o código Mule para lidar com cada caso. No final, veremos como podemos combinar os dois casos.

Se houver erro, continue

O Se houver erro, continue manipulador funciona de forma semelhante ao Java pegar demonstração. Isso é usado para lidar com o problema onde ele ocorre e permite a execução normal para Prosseguir.

No exemplo acima, nós pegar uma ArithmeticException, que ocorre na linha 16. Execução então pula o logger na linha 18 e pula para a linha 24, onde definimos o resultado como “infinito” e o retornamos, como se nenhum erro tivesse ocorrido. O que quer que tenha chamado esse método simplesmente obtém o valor de Integer.MAX_VALUE retornado, sem nenhuma indicação de que uma exceção foi tratada.

Esta é a aparência desta parte da implementação no Mule:

Em Java e Mule, a mensagem de log é pulado se a divisão falhar. Independentemente de a divisão inteira ter sido bem-sucedida, um valor inteiro é retornado e o chamador acredita que o fluxo foi executado com sucesso.

Para retornar o campo Java estático Integer.MAX_VALUE, podemos usar o módulo Java do Mule diretamente em nosso transformador Set Payload:

valor = ”#[java!java::lang::Integer::MAX_VALUE]”

doc: name = ”java! java :: lang :: Integer :: MAX_VALUE” />

Observe isso em vez de um ponto final. usamos dois pontos duplos :: para delimitar pacotes no Mule.

Algumas versões do Anypoint Studio podem sinalizar o acima com um erro de validação “Incapaz de resolver a referência”. Este é um problema conhecido com o módulo de validação e pode ser ignorado neste caso.

Em caso de propagação de erro

O Em caso de propagação de erro manipulador funciona de forma semelhante ao Java lança demonstração. Isso é usado quando precisamos que o chamador saiba que ocorreu um problema, se, por exemplo, não formos capazes de lidar com o problema em sua origem.

No exemplo Java acima, se x ou y não podem ser analisados ​​em um valor inteiro, nós lançar uma NumberFormatException na linha 13 ou na linha 14. Essa exceção é então propagada acima a pilha de chamadas, onde precisa ser tratada por qualquer método chamado integerDivision ().

Esta é a aparência da implementação no Mule:

Neste caso, se nenhum ocorrer um problema, o erro é simplesmente jogado de volta na pilha e os processadores Transform Message e Logger não são executados. Como não queremos realizar nenhuma ação nesse caso, o escopo de propagação de erro é deixado vazio.

Também podemos especificar ações a serem tomadas antes lançando / propagando o erro, adicionando-os ao escopo de propagação de erro. Em Java, isso exigiria um bloco extra try / catch.

Experimente (escopo)

Vamos combinar os dois fluxos para fornecer uma representação de uma implementação Mule do código Java de exemplo.

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br

Nosso problema imediato é, se tivermos vários manipuladores de erro (aqui on-error-continue e on-error-propagate), precisamos especificar namespaces de erro para eles ouvirem. O último manipulador de erros (aqui na propagação do erro) detectará todos os outros erros se não definir um namespace de erro.

A razão pela qual isso é um problema é que no Mule, tanto uma conversão falhada de uma String para um Número e uma divisão por zero geraria um erro MULE: EXPRESSION. Isso ocorre porque os dois problemas ocorrem em uma expressão DataWeave.

Para lidar com os dois erros de forma diferente, temos que criar um tipo de erro personalizado dentro do Mule, levantar aquele erro dentro de um escopo Try, e então propagar para que o chamador (o fluxo) tenha que lidar com isso.

Depois de fazer essas alterações, a implementação do Mule pode ser parecida com esta:

Aqui nós levantar um erro com um tipo personalizado de APP: ARITHMETIC_EXCEPTION se tentarmos dividir por zero. Nós então propagar o erro até. Isso significa que ele precisa ser tratado por qualquer que seja chamado de escopo Try – que, neste caso, é simplesmente o fluxo integerDivider. O tratamento de erros em nível de fluxo assume, então, e o manipulador on-error-continue pega o erro APP: ARITHMETIC_EXCEPTION, define uma carga útil padrão e a retorna como se o fluxo tivesse sido concluído com sucesso.

Se as variáveis ​​de entrada não puderem ser mapeadas no tipo Number, isso gerará um erro MULE: EXPRESSION, que será então manipulado e lançado pelo manipulador on-error-propagate. Nesse caso, não há ações a serem executadas, então o manipulador simplesmente lança o erro na pilha. Em seguida, ele precisa ser tratado por qualquer coisa originalmente chamada de fluxo integerDivider.

Aqui está o código XML do Mule para o fluxo integerDivider:

<flow name="integerDivider">
   	 <set-variable value="#[vars.x as Number]" doc:name="intx = vars.x as Number" variableName="intx"/>
   	 <set-variable value="#[vars.y as Number]" doc:name="inty = vars.y as Number" variableName="inty"/>
   	 <try doc:name="Try">
   		 <ee:transform doc:name="divide-intx-by-inty">
   		 <ee:message>
   			 <ee:set-payload><![CDATA[%dw 2.0
output application/dw
---
vars.intx / vars.inty]]></ee:set-payload>
   		 </ee:message>
   	 </ee:transform>
   		 <error-handler >
   			 <on-error-propagate enableNotifications="false" logException="false" doc:name="On Error Propagate">
   				 <raise-error doc:name="APP:ARITHMETIC_EXCEPTION" type="APP:ARITHMETIC_EXCEPTION" description="APP:ARITHMETIC_EXCEPTION" />
   			 </on-error-propagate>
   		 </error-handler>
   	 </try>
   	 <logger level="INFO" doc:name=""Successfully performed integer division."" message="Successfully performed integer division."/>
   	 <error-handler >
   		 <on-error-continue enableNotifications="false" logException="false" doc:name="On Error Continue" type="APP:ARITHMETIC_EXCEPTION">
   			 <set-payload value="#[java!java::lang::Integer::MAX_VALUE]" mimeType="application/dw" doc:name="java!java::lang::Integer::MAX_VALUE"/>
   			 <logger level="INFO" doc:name="Logger" message="#[payload]"/>
   		 </on-error-continue>
   		 <on-error-propagate enableNotifications="false" logException="false" doc:name="On Error Propagate" type="MULE:EXPRESSION"/>
   	 </error-handler>
    </flow>

Mapeamento de erro

Em Java, podemos criar nossas próprias exceções personalizadas e o Mule nos permite fazer o mesmo. A diferença é que no Mule, podemos simplesmente declarar um tipo de erro customizado embutido – como APP: ARITHMETIC_EXCEPTION acima – sem ter que declarar e implementar uma nova classe Exception. Tudo o que precisamos fazer é declarar o tipo de erro personalizado dentro de um componente Raise Error.

No Mule, podemos mapear um tipo de erro existente para um personalizado. Isso seria feito no componente Mule que gera o erro.

Erros de sistema e mensagens

Os erros do sistema são causados ​​por problemas no nível do sistema Mule, por exemplo, problemas com o próprio Mule Runtime ou conexões com falha em um sistema externo. Os erros do sistema são como instanciações da classe Java java.lang.Error: eles indicam “problemas sérios que um aplicativo razoável não deve tentar detectar”. No MuleSoft, você não pode detectar ou tratar especificamente um erro de sistema.

Os erros de mensagens, por outro lado, indicam problemas dos quais o aplicativo deve tentar se recuperar ou tratar. São como instanciações da classe Java java.lang.Exception. Os erros de mensagens podem ser detectados e tratados de maneira semelhante às Exceções Java.

Conclusão

Nesta postagem, mostramos como pensar nos componentes de tratamento de erros da MuleSoft em termos de tratamento de exceções Java. Para mais postagens sobre tratamento de erros no Mule, você pode pesquisar a tag “tratamento de erros” ou clicar neste link.

Mais adiante nesta série, veremos outros conectores e processadores de eventos comuns no Mule e os compararemos e contrastaremos com as terminologias Java comuns. Para mais táticas de tratamento de erros, verifique esta série de blog sobre desmistificação do tratamento de erros no Mule.

[ad_2]

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
Luiz Presso
Luiz Presso