Как да подтискам предупрежденията на Eclipse 3.5 за мъртъв код

Използвам клас за откриване на имейл адреси, който използва статични крайни булеви стойности за конфигуриране на поведението на съвпадение. Тъй като надстроих до Eclipse 3.5, получавам предупреждения за мъртъв код, тъй като Eclipse забелязва, че един клон в това не може да бъде достигнат:

private static final boolean ALLOW_DOMAIN_LITERALS = false;
private static final String domain = ALLOW_DOMAIN_LITERALS ? rfc2822Domain : rfc1035DomainName;

Колкото и да е странно, той е доволен от това:

private static final String domain;
static {
    if(ALLOW_DOMAIN_LITERALS) {
        domain = rfc2822Domain;
    } else {
        domain= rfc1035DomainName;
    }
}

тъй като изглежда, че разпознава общия модел if(DEBUG), но троичният оператор изглежда не се брои.

Тъй като предпочитам да не разклонявам класа твърде много, само за да поддържам Eclipse щастлив, бих предпочел да сложа @SuppressWarnings в горната част, вместо да променям кода. За съжаление не мога да намеря подходящ освен brute-force "all". Има ли стойност само за откриване на мъртъв код?


person Peter Becker    schedule 06.07.2009    source източник


Отговори (3)


АКТУАЛИЗАЦИЯ: от коментара на Адам:

В Eclipse 3.6 и по-новите версии на Eclipse @SuppressWarnings("unused") вече може да се използва за потискане на предупрежденията за "мъртъв код". Вижте отговора на Кристофър Сток.

Вижте също Eclipse 4.4(Luna ) помощ за @SuppressWarnings.

Оригинален отговор:

Всички стойности на SuppressWarnings, които Eclipse 3.5 "познава", са изброени в тази страница. Изглежда, че няма стойност за потискане само на новото откриване на мъртъв код. Но можете да използвате @SuppressWarnings("all") точно преди декларацията domain, така че да потиска предупрежденията само за този ред, а не за целия клас:

private static final boolean ALLOW_DOMAIN_LITERALS = false;
@SuppressWarnings("all") 
private static final String domain = ALLOW_DOMAIN_LITERALS ? rfc2822Domain : rfc1035DomainName;

Тъй като проверката на мъртъв код е нова, можете също да предложите подобрение в база данни за грешки на Eclipse за поддръжка троичната операция също.

person Csaba_H    schedule 06.07.2009
comment
Ето записа в bugzilla: bugs.eclipse.org/bugs/show_bug.cgi? id=282768 Bugzilla със сигурност няма както дублираното търсене, така и Wiki синтаксиса, който StackOverflow предлага :-) - person Peter Becker; 08.07.2009
comment
Добавих и едно за липсващите @SuppressWarnings: bugs.eclipse.org/bugs /show_bug.cgi?id=282770 - person Peter Becker; 08.07.2009
comment
Състоянието на двете заявки вече е потвърдено - person Casebash; 17.05.2010
comment
Изглежда, че не можете да направите това за определен ред в метод. Трябва да се направи за цял метод, в противен случай се показва грешка при вмъкване на EnumBody. - person Adam; 12.09.2010
comment
@SuppressWarnings("unused") вече може да се използва за потискане на това, вижте отговора на Кристофър Сток - person Adam Rosenfield; 12.09.2013

Изберете Ignore в Windows -> Preferences > Java > Compiler > Errors/Warnings под Potential programming problems раздел

person J-16 SDiZ    schedule 06.07.2009
comment
Но като цяло харесвам функцията, тук просто се проваля. Ако това беше мой собствен код, просто бих го променил. Можете също така да го деактивирате на ниво проект (т.е. да активирате специфичните за проекта настройки на компилатора в свойствата на проекта), но аз дори не искам да правя това. - person Peter Becker; 08.07.2009

Можете да деактивирате предупрежденията за „мъртъв код“, като използвате

@SuppressWarnings( "unused" )

Вижте документацията на eclipse за повече информация:

http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-suppress_warnings.htm

"unused" за потискане на предупреждения относно неизползван код и мъртъв код

Поздравления

Кристофър

person Christopher Stock    schedule 01.08.2013
comment
Гласувах, тъй като може да е полезно за някой, който идва тук. Функцията не съществуваше тогава, но сега съществува (вижте проблеми с Bugzilla, свързани в моите коментари за приетия отговор). - person Peter Becker; 02.08.2013