Dev Faq
10
votes

Java: Comment @Suppresswarnings Code inaccessible?

Parfois, lorsque vous débogageez, vous avez un fragment de code inaccessible. Est-il de toute façon pour supprimer l'avertissement?

6 commentaires

Probablement pas - le code inaccessible est généralement un signe d'une méthode mal codée .. Pourriez-vous le poster? Doit être un moyen de le refroidir.

On dirait qu'il a ajouté un retour rapide, ou éventuellement un si (faux) ... , pour le débogage. Aucun problème avec cela.

Pourquoi supprimer l'avertissement pendant le débogage? L'avertissement est là pour vous rappeler de supprimer le code après avoir terminé le débogage - IMO C'est le meilleur pas pour supprimer les avertissements liés au débogage. La suppression a du sens pour des avertissements connus et inutiles dans code de production .

@Vaxquis mais certains codes ne sont pas destinés à atteindre la production de jamais. Cela ne veut pas dire que vous écririez de mauvais code mais moins d'avertissements seraient gentils.

@MOHAMMAMMADMOGHIMI Je n'ai jamais dit que c'était mauvais - mais: si c'est "grave", dans ce cas, il devrait être fixé au lieu d'utiliser une suppression d'avertissement. Si ce n'est pas le code «sérieux», l'avertissement n'aurait pas d'importance: soit vous écrivez le code comme «écrire une fois, exécutez de nombreuses» (par exemple, une regex) - et ensuite vous simplement Ne revenez pas à ce code (auquel cas l'avertissement ne vous fait pas mal - laissez-le seul!) - ou vous écrivez le code de débogage - dans quel cas utilisez l'avertissement pour vous rappeler le code de débogage pour vous rappeler le code de débogage. Enlevé - ou c'est "sérieux" (réutilisable, aka production code), auquel cas juste ne ne le supprimez pas!

@Vaxquis je ne peux pas être d'accord plus d'accord.

4 Réponses :

6
votes

Le seul moyen de le faire sur n'importe quel compilateur est @suppresswarnings ("tout") .

Si vous utilisez Eclipse, essayez @suppresswarnings ("inutilisé") .

2 commentaires

Ce n'est pas le seul moyen du tout. Voir ma réponse ( Stackoverflow.com/a/6025389/8946 ).

@Softwaremonkey Votre approche provoque toujours des avertissements à Eclipse et Intellij. Ceci est la seule solution qui fonctionne à travers les compilateurs et les IDes.

4
votes

comme Cletus nous ,

Cela dépend de votre IDE ou de votre compilateur.

Cela dit, au moins pour Eclipse, il n'ya pas de moyen de le faire. Avec ma configuration Eclipse, le code inaccessible provoque une erreur de compilation, pas seulement un avertissement. Notez également que cela est différent du "code mort", par exemple " xxx

pour laquelle Eclipse (par défaut) émet un avertissement, pas une erreur.

1 commentaires

Vous pouvez modifier le code de "inaccessible" en "morts" en utilisant "si (vrai)" devant la déclaration de retour ou de lancement.

11
votes

Java a la prise en charge (primitive) pour déboguer comme celle-ci dans ce simple si code> sur les constantes booléens ne générera pas de tels avertissements (et, en effet, lorsque l'évaluation est fausse, le compilateur retirera tout le bloc conditionné) . Donc, vous pouvez faire: 

public class Debug
{
static public final boolean ON=false;
}

...

if(Debug.ON) {
    ...
    }

6 commentaires

Javac ne génère pas d'avertissements pour si (faux) , mais le compilateur Eclipse fait.

@Daniel: C'est malheureux; Il ne devrait pas pour une bronde si (faux) ou lorsque la seule variable de condition est statique finale Boolean défini sur false .

J'aime l'avertissement parce que cela me rappelle de revenir en arrière et de faire quelque chose sur le code mort, mais IIRC il est fait défaut à une erreur dans une ancienne version d'Eclipse, alors je serais recourir à des trucs comme si (math.abs (0) == 0) .

+1 Cela ne provoque pas d'avertissements de "code mort" en Java. La clé est que votre drapeau booléen constant doit être la seule expression dans le si . Si vous utilisez si (debug.on) cela fonctionnera, mais if (débogued && anotherexpression) ne fonctionnera pas (générer un avertissement). À propos, l'avertissement "Code Dead" n'est pas équivalent au "Code inaccessible" Erreur .

@Daniel: votre exemple, si (math.abs (0) == 0) n'est pas le genre d'expression constante dont je parle; Ce que je dis, c'est seulement ceux qui sont ou sont encastrés à si (faux) ou si (vrai) . Lorsqu'une variable constante est utilisée dans le code de la valeur et non, la référence est inlinée par le compilateur. Vous devez lire la spécification sur la différence entre une finale constante et une finale inconstante (ou sur une valeur dérivée d'une valeur dérivée).

@Softwaremonkey Le JLS dit simplement que si (faux) "n'entraîne pas une erreur de compilation", pas que cela ne peut pas causer des avertissements. Les compilateurs "peuvent choisir d'omettre le code pour cette instruction du fichier de classe généré", mais il n'y a aucune exigence et le retrait peut être fait après avoir généré des avertissements de toute façon. Le dernier compilateur Eclipse avec paramètres par défaut génère un avertissement pour si (faux) . Intellij génère également un avertissement "constant" si "déclaration".

4
votes

Selon le Spécification de la langue Java :

C'est une erreur de compilation si une instruction ne peut pas être exécutée car elle est inaccessible.

Vous pouvez parfois transformer le code inaccessible en code mort (par exemple, le corps de if (false) {...} ). Mais c'est une erreur fait partie de la définition de la langue.

0 commentaires

Articles qui pourrait vous intéresser :

Comment envoyer une liste vide à la clause IN
Code de réponse 403 inattendu lors de la récupération des données des API
Impossible de trouver la classe UnityPlayerActivity dans com.unity3d.player
Comment définir un tableau dans jsonobject