contrats vs Exceptions

Supposons que je le code suivant:contrats vs Exceptions

public class MainClass { 
    public static void main(String[] args) { 
     System.out.println(sumNumbers(10, 10)); 
    } 

    //@requires a >= 10; 
    //@ensures \result < 0; 
    public static int sumNumbers(int a, int b) { 
     return a+b; 
    } 
}

je peux faire 2 choses ici:

Utilisez le code des marchés (dans ce cas, ce qui est dans les commentaires). Lorsque sumNumbers est exécuté et un < 10, il lancera immédiatement une exception (bien qu'il ne semble pas être très descriptif):

Exception in thread "main" org.jmlspecs.jmlrac.runtime.JMLInternalNormalPostconditionError: by method MainClass.sumNumbers 
    at MainClass.sumNumbers(MainClass.java:500) 
    at MainClass.internal$main(MainClass.java:9) 
    at MainClass.main(MainClass.java:286)

ou ...

renverrait une exception dans. L'exception peut être aussi descriptive que je le souhaite. Je voudrais également vérifier à la fin de la fonction pour voir à chaque fois que les conditions de publication sont vraies ou non.

qui utiliseriez-vous ici et pourquoi?

Source

2010-03-18 devoured elysium

J'aime l'idée des contrats de code, mais les IllegalArgumentException descriptives (ou similaires) des conseils pour moi. Il est beaucoup plus clair dans un rôle de support/production (ou même développement) d'obtenir un message d'exception explicite, ce qui vous permet de diagnostiquer ce qui ne va pas (si un système est cassé ou si vous abusez d'une API pendant le développement).

Source

2010-03-18 20:55:21

meilleure idée: utilisez les deux! –

Si vous le pouvez, oui. Je ne suis pas familier avec les «contrats de code» tels que présentés ci-dessus –

Il ne servirait à rien d'utiliser les deux. L'idée d'avoir un contrat de code indiquant que x> = 0 est que je n'ai pas à le vérifier à nouveau dans le corps de la méthode. Donc, il ne sert à rien d'utiliser les deux. –

vous attendez-vous que les entrées invalides pourraient être transmis à cet argument lors du fonctionnement normal de votre programme? Si oui, pouvez-vous vous en remettre?

Si oui, vérifier des exceptions sont la voie à suivre.

Si vous ne pouvez pas récupérer de ce genre de cas, par tous les moyens en font un contrat et ne parviennent fort - mais dans les deux cas, j'utiliser un message d'erreur descriptif.

Source

2010-03-18 20:53:42 danben

Répondre

Questions connexes