Que pensez-vous de retourner la phrase de l'exploitation forestière

Question

Je le code java:

if(isNull(office) || isNull(pricelist)) { 
    log.warn("The document {0}-{1} is not valid.",codDoc,numDoc); 
    return null; 
} 

Pensez-vous qu'il est ok si je réécris comme:

if(isNull(office) || isNull(pricelist)) 
    return log.warn("The document {0}-{1} is not valid.",codDoc,numDoc); 

De cette façon

public void warn(String logLine, Object... args) 
{...} 

deviendrait:

public Object warn(String logLine, Object... args) 
{...;return null;} 

Tenez compte du fait que la journalisation est obligatoire dans ce système. Merci pour vos commentaires.

Answer 1

Je ne ferais jamais cela car cela crée une API surprenante. En Java en particulier, le point n'est pas la tersness, le point est la clarté. Avoir une ligne supplémentaire pour le retour est précieux car il vous indique que le retour n'est pas lié à la journalisation.

Et si vous êtes dans une méthode qui a elle-même un retour vide, vous devrez quand même mettre le retour sur une ligne séparée.Et de toute façon, si vous le déclarez pour retourner Object, la méthode doit retourner Object, ou bien vous devez le supprimer, ce qui est encore pire. Vous pouvez travailler avec les génériques que:

public <T> T warn(String message, Object... params) { return null; } 

Mais rien de tout cela semble être une bonne idée dans le cas général.

Answer 2

Cela dépend de ce que vous avez besoin de la journalisation à faire.

Si votre système doit avoir un objet créé comme une exception pendant le processus de consignation, la seconde méthode (Object warn()) peut fonctionner pour vous.

Cela dépend vraiment de ce que vous avez besoin ....

Answer 3

Si vous allez toujours revenir nulle de la méthode warn, alors il ne fera aucune différence dans les deux cas; aucune fonctionnalité supplémentaire n'est activée et aucune information supplémentaire n'est fournie. J'effectuerais la modification uniquement si une entité externe exige que votre méthode de journalisation corresponde à une signature où Object est renvoyé.

Answer 4

Je ne pense pas que ce soit OK pour le réécrire comme vous l'avez suggéré.

Couple de raisons.

1. De nombreuses API standard du journal ont void le type de retour pour la méthode warn. Pour quelqu'un familier avec ces API, il serait un surprizing méthode effet secondaire
2. Votre warn ne retourne pas un objet réel , il retourne toujours null. Ce serait surprizing pour le mainteneur de le savoir.

Answer 5

Utilisez la première méthode.

La raison en est que la seconde méthode implique que la valeur de retour de la méthode warn est significative. La deuxième méthode, comme écrite, force la valeur de retour de la méthode warn à apparaître comme si elle était la valeur de retour de l'appelant de la méthode warn et c'est probablement la mauvaise chose à retourner, surtout si le design a plusieurs valeurs de retour gérer diverses conditions d'avertissement.