Je me demande si beaucoup de gens sont programmés en Java avec des assertions. Je pense que cela peut être très utile sur de grands projets sans suffisamment de contrats écrits ni de contrats obsolètes. En particulier lorsque vous utilisez desservices, des composants, etc.
Mais je n'ai jamais vu de projet à l'aide d'assertions (sauf dans les tests Junit / Test ...).
J'ai remarqué que la classe lancée est une erreur et non une exception . Pourquoi choisissent-ils une erreur? Peut-il être parce qu'une exception pourrait être prise de façon inattendue et non connectée / redethrown?
Si vous développez une application avec des composants, je me demande où vous mettez les assertions:
Je comprends comment utiliser des affirmations, et lorsque vous les utilisez, mais je vous demande simplement si certaines personnes ont des recommandations basées sur une expérience réelle d'affirmations.
4 Réponses :
Au fait, faites-vous référence à Je trouve personnellement des assertions particulièrement utiles pour les invariants.
Prenez en compte la vérification de l'assertion est désactivée par défaut en Java. Vous devez ajouter le drapeau En d'autres termes, vous pouvez tester votre application dans une sorte de mode de débogage, où le programme arrête une fois qu'une affirmation est cassée. D'autre part, l'application de version aura été désactivée et n'entraînera pas une pénalité de temps pour la vérification de l'affirmation. Ils seront ignorés.
En Java, les affirmations sont beaucoup moins puissantes que les exceptions et ont des significations totalement différentes. Exceptions sont là lorsque quelque chose d'inattendu se produit et que vous devez le gérer. Les affirmations concernent l'exactitude de votre code. Ils sont ici pour confirmer que ce que "devrait être" est bien le cas.
Ma politique approximative, surtout lorsque vous travaillez avec de nombreux développeurs:
... Mais en fait, je les utilise de manière élégante. Juste où il est critique ou sur des endroits sujets d'erreur. ASSERT EN JAVA?
-aa pour activer la vérification de l'assertion.
Avez-vous déjà retourné des affirmations dans les productions?
J'ai tendance à les désactiver dans la production et à les utiliser uniquement pour tester / déboguer ...
À propos de l'utilisation mineure d'affirmations, je pense que c'était une mauvaise décision de faire des affirmations désactivées par défaut.
À propos de l'extension Error Je suppose qu'il étend Error car Error s sont des exceptions qui ne devraient pas être capturées. Et de cette façon, lorsque vous avez dans votre code, vous avez et à propos de l'utilisation, le meilleur endroit est en précotions, postconditions ou au milieu du code dans n'importe quel invariant que vous souhaitez vérifier. attrape (exception) , l'affirmation n'est pas mise en cache.
À mon avis, des erreurs de Java doivent être traitées comme une exception. Par conséquent, je permettrais aux affirmations dans le développement et aux méthodes privées de vérifier que mon code fonctionne bien et ne transmet pas des valeurs non valides aux méthodes privées.
Étant donné que ces chèques devraient être effectués dans des méthodes publiques, je ne vérifierais pas à nouveau dans des méthodes privées.
Afin de désactiver les assertions:
À mon avis, dans les méthodes publiques, vous devriez vérifier et gérer l'exception ou les enregistrer vous-même. -Da drapeau dans compilateur
Pourquoi la désactiver dans la production? Je tiendrais une instance avec des assertions activées car les Somestimes que nous utilisons des composants (de nous ou de la tierce partie) qui pourraient avoir différentes configurations dans la production et que les contrats ne pouvaient être brisés que dans la production env ...
Assertions Vérifiez les contrats et il peut y avoir des contrats dans des méthodes publiques afin ...? S'il vous plaît, ne me dites pas ce que vous ferez sans expliquer pourquoi;) ne pouvons-nous pas envisager un contrat brisé pourrait être un problème différent d'un problème de programmation? Une application pourrait continuer à fonctionner avec un contrat brisé et des affirmations handicapées, tandis qu'une fois que vous avez défini une exception pour vérifier un contrat, il vous suffit de faire une autre livraison ... et ce contrat peut être brisé à tout moment (ex vous appelez un URL fournissant des données via httpclient, mais l'URL que vous appelez a été mise à jour et certaines données sont manquantes ...)
Et quel est le point de faire des affirmations que dans des méthodes privées? Ensuite, je vais mettre tout mon code dans des méthodes privées avec des assertions et faire des méthodes publiques qui appellent simplement les méthodes privées et ce serait ok pour vous?
Eh bien, s'il y a quelque chose que je pense que cela peut échouer au moment de l'exécution, je le vérifierais puis gérer l'erreur comme une exception ou simplement le loger. Quand je dis des méthodes privées, je pense à un morceau de code que je contrôle et nourrit avec des paramètres. Si ces paramètres provient d'un système externe, il avait passé une méthode publique. Étant donné que ces paramètres peuvent avoir des valeurs non valides, je les vérifierais et ne vérifiez plus dans la méthode privée. Désolé pour mon pauvre anglais, et encore une fois, c'est juste mon opinion.
Bien sûr, vous vérifiez toujours les paramètres des exceptions ... Ce n'est pas le point d'affirmation, mais de toute façon, je ne vois rien de mal dans la vérification de l'invariant dans des méthodes publiques. Ce n'est pas parce qu'une méthode est publique que vous ne pouvez rien affirmer que les paramètres de méthodes.
Comme dit, pour moi, le point clé est que vous devez utiliser des exceptions ou affirmer dans votre code pour vérifier quoi que ce soit. Et j'utiliserais des exceptions. De toute évidence, Java fournit des affirmations. Il est donc correct de les utiliser. Je vois cela comme une question de préférences.
Les assertions ne doivent pas être utilisées en dehors des tests car elles peuvent être désactivées dans un environnement de production, ce qui peut causer de graves problèmes en raison de l'absence de vérification correcte.
Cependant, j'ai vu une déclaration selon laquelle il est autorisé à les utiliser pour vérifier les paramètres de méthodes privées. En effet, vous supposez que les données qui ont réussi à atteindre votre méthode privée sont correctes et si ce n'est pas l'application, peut échouer fort.
En fait, mon point n'a jamais été de remplacer les exceptions par des assertions. Tourner les affirmations offrait ne changerait pas le comportement de mon application ...