Est-il possible d'essayer et d'attraper quelque chose juste pour vérifier si une exception a été levée ou non ?

Question

Est-ce une bonne façon d'essayer quelque chose d'inutile juste pour voir si une exception particulière est levée par ce code ?
Je veux faire quelque chose lorsque l'exception est levée, et rien sinon.

try {  
    new BigDecimal("some string"); // This do nothing because the instance is ignored  
} catch (NumberFormatException e) {  
    return false; // OK, the string wasn't a well-formed decimal  
}  
return true;

Il y a trop de conditions préalables à tester, et le constructeur BigDecimal() les vérifie toujours toutes, ce qui semble être la méthode la plus simple.

Answer 1

En général, cette pratique doit être évitée. Mais comme il n'existe pas de méthode utilitaire isValidBigDecimal(..) c'est ce qu'il faut faire.

Comme Peter Tillemans l'a noté dans les commentaires, placez ce code dans une méthode utilitaire appelée isValidBigDecimal(..) . Ainsi, votre code sera agnostique quant à la manière de déterminer la validité, et vous pourrez même passer ultérieurement à une autre méthode.

Boris Pavlović a suggéré une option pour vérifier cela en utilisant une bibliothèque tierce (commons-lang). Il existe une autre méthode utile, que j'utilise chaque fois que j'ai besoin de vérifier des nombres. NumberUtils.isNumber(..)

Answer 2

Si vous n'aimez pas avoir une méthode comme celle-ci, essayez d'utiliser BigDecimalValidator de Valideur Apache Commons . Dans le cas d'une entrée invalide String il retourne null .

Answer 3

Il n'y a rien de mal à faire cela ; après tout, les partisans d'une certaine langue se plaisent à dire "il est plus facile de s'excuser que de demander la permission", c'est-à-dire qu'il est plus facile d'attendre que quelque chose échoue et d'y faire face que d'éviter l'échec. Dans ce cas, puisqu'il n'y a pas d'alternative, il faut absolument foncer.

Answer 4

Les performances ne sont peut-être pas excellentes et la syntaxe est verbeuse, mais le code est très précis quant à ce qu'il fait. Il n'y a pas de duplication entre la vérification et l'utilisation, ce qui est toujours une grande préoccupation.

(Remarque : ce type particulier de conversion vers et depuis des chaînes de caractères est vraiment destiné au débogage et à la configuration interne. Il ne gère pas les locales et autres considérations orientées homme. L'utilisation dans les formats de fichiers et les protocoles de fil introduit une forte dépendance à la représentation utilisée par la classe).

Answer 5

Il existe deux méthodes connues pour "vérifier" les conditions préalables.

LBYL : Regarde avant de sauter

Ce style de codage teste explicitement les pré-conditions avant d'effectuer des appels ou des recherches. Ce style contraste avec l'approche EAFP et se caractérise par la présence de nombreuses instructions if.

EAFP : Il est plus facile de demander le pardon que la permission.

Ce style de codage courant suppose l'existence de clés ou d'attributs valides et génère des exceptions si l'hypothèse s'avère fausse. Ce style propre et rapide est caractérisé par la présence de nombreuses instructions try et except. Cette technique contraste avec le style LBYL commun à de nombreux autres langages comme le C.

L'EAFP est toujours une bonne idée pour les langues qui ont une typographie de canard.

Cela dépend clairement de ce que vous voulez faire... Si vous n'êtes pas sûr du type d'objet à manipuler, utilisez l'EAFP.