Est-ce une mauvaise pratique?

Le code suivant est-il considéré comme une mauvaise pratique? Pensez-vous que cela peut être fait autrement? L'objectif est de toujours mettre à jour le statut, que ce soit avec succès (c.-à-invocation à service.invoke (id), retourne normalement) ou à l'échec ...Est-ce une mauvaise pratique?

@Autowired 
private Service service; 

public void onMessage(Message message) { 

    String id = null; 
    String status = "FAILED"; 

    try { 
     id = ((TextMessage) message).getText(); 
     status = service.invoke(id); //can throw unchecked exception 
    } catch (final JMSException e) { 
     throw new RuntimeException(e); 
    } finally { 
     if (StringUtils.isNumeric(id)) { 
     service.update(id, status); 
     } 
    } 
}

Source

2013-03-11 boom123

Mettez ce code de mise à jour 'default', dans votre' catch' et une fois terminé, lancez votre exception. Évitez la clause 'finally'. – SudoRahul

@JustinYang que voulez-vous dire exactement? Le 'finally' sera appelé _after_ le' try'. Que voulez-vous dire par "avaler"? –

@ bmorris591 a raison. Le 'throw' arrivera toujours après l'exécution du bloc' finally'. Il serait avalé si le 'enfin' a également jeté une exception. –

Cela dépend de votre cas d'utilisation, si vous avoir à effectuer une étape ou non en fonction de l'étape précédente. En utilisant finalement, vous pouvez exécuter votre seconde étape, quelle que soit l'exception que vous pourriez recevoir.

Je vous recommande d'avoir la deuxième étape en dehors du bloc try...catch afin que vous ne mettiez à jour que si vous avez une exception que vous avez attendue et passez à la deuxième étape, sinon votre méthode lancera et quittera.

Source

2013-03-11 14:21:28

J'ai mis à jour mon code, invocation à service.register (id); peut lancer une exception non interceptée, que je veux propager et annuler la trascaction. Mais j'ai encore besoin de mettre à jour cet échec ... – boom123

Étant donné que son catch jette une exception, le code après le catch ne sera jamais vu à moins qu'il ne soit dans un final. –

Vous pouvez envelopper 'service.register (id);' dans un 'try ... catch' où vous attrapez l'exception, vous attendez. Unchecked est juste que votre compilateur ne vous demandera pas de le gérer afin que votre catch puisse l'obtenir. Seulement, 'Error' ne peut pas être manipulé par' catch'. Dans ce cas, 'finally' ne vous aidera pas, car cela va vider votre discussion. Notez ce statut et lancez une exception si vous voulez que l'appelant connaisse le statut. La raison, je suggère de cette façon est que vous pouvez avoir plusieurs étapes après l'échec, que vous n'avez pas à mettre à l'intérieur finalement. –

Je pense que vous ne devriez pas utiliser l'implémentation de l'écouteur de message, vous devriez les câbler indépendamment de spring tech. juste basé sur pojo. utilisez <jms:listener-container > avec <jms:listener>

Source

2013-10-04 08:09:39

pouvez-vous donner des explications supplémentaires sur les raisons pour lesquelles vous pensez que l'autoforage au printemps est mauvais? – eis

Je ne parle pas de câblage automatique. Je prends à propos de "MessageListener" –

Le printemps en action ch 13 page 326 –

Est-ce une mauvaise pratique?

Répondre

Questions connexes