W jaki sposób mogę wykryć martwy kod po metodach zawsze rzucających?

Question

rozważyć następujący kod:

@Test 
public void testDeadCode() { 
    letsThrow(); 
    System.out.println("will never be reached"); 
} 

private final void letsThrow() { 
    throw new RuntimeException("guess you didnt see this one coming"); 
} 

Dla mnie wydaje się absolutnie niemożliwe, że println() zostanie kiedykolwiek zrealizowany - jako wezwanie do letsThrow() będzie zawsze wyjątek.

Dlatego jestem

a) zaskoczony, że kompilator nie może mi powiedzieć „to jest martwy kod”

b) zastanawiać, czy istnieją pewne flagi kompilatora (lub eclipse ustawienia), które mogłyby spowodować mówiąc: masz tam martwy kod.

Answer 1

Błędy w czasie kompilacji martwego kodu są określane przez kompilator, a nie przez IDE. Chociaż jest prawdą, kod nigdy nie zostanie wykonany, nie narusza żadnych zasad dotyczących nieosiągalnych instrukcji z Dokumentów Oracle.

Od Unreachable Statements

Ten rozdział poświęcony jest dokładnym wyjaśnieniem słowa „osiągalny”. Chodzi o to, że musi istnieć jakaś ścieżka wykonywania od początku konstruktora, metody, inicjalizatora instancji lub inicjalizatora statycznego, który zawiera instrukcję do samej instrukcji. Analiza uwzględnia strukturę oświadczeń. Poza specjalnym traktowaniem while, do i dla instrukcji, których warunek ma stałą wartość true, wartości wyrażeń nie są brane pod uwagę w analizie przepływu.

Zasady obowiązujące w tym przypadku zależą od tego, czy bloki, które utworzyłeś, są osiągalne. (iff = if i tylko jeśli)

Pusty blok, który nie jest blokiem przełączającym, można zakończyć normalnie, jeśli jest on osiągalny.

Niepusty blok, który nie jest blokiem przełączającym, może zakończyć się normalnie, a ostatnia instrukcja w nim może zakończyć się normalnie.

Pierwsza instrukcja w niepustym bloku, który nie jest blokiem przełączników, jest osiągalna, jeśli blok jest osiągalny.

Każda inna instrukcja S w niepustym bloku, który nie jest blokiem przełączającym, jest dostępna iff instrukcja poprzedzająca S może zakończyć się normalnie.

Sposób letsThrow spełnia kryteria dla bloku roboczego kodu i technicznie uzupełnia normalnie. Zgłasza wyjątek, ale kończy. To, czy zgłasza wyjątek gwarantowany, nie jest brane pod uwagę przy ustalaniu, czy ten blok kodu w jego rzeczywistym użytkowaniu, , czy jest dostępny, czy nie, może zostać osiągnięty. W większości przypadków, martwy kod zostanie znaleziony tylko wtedy, gdy będzie zawierał try/catch/return, które stanowią większość reguł.

Rozważmy następujące, nawet bardziej zwięzły wersja:

@Test 
public void testDeadCode() { 
    System.exit(0); 
    System.out.println("will never be reached"); 
} 

Nie ma prawdziwego Licznik ten oprócz starannego użycia narzędzi pokrycia, ale jasne strony w przykładzie zobaczysz gwarantowane wyjątków za każdym razem uruchamiasz kod.

Answer 2

Celem jest przeprowadzenie kompleksowych testów jednostkowych i pomiary zasięgu testu. Martwy kod będzie widoczny, ponieważ żaden z twoich testów nie spowoduje jego wykonania.

Answer 3

Deklarują swoją metodę jako powrót typ Throwable:

private final RuntimeException letsThrow() { 
    throw new RuntimeException("guess you didnt see this one coming"); 
} 

Następnie można wyrzucić, gdy nazywają go:

throw letsThrow(); 

Teraz każdy kod, który następuje wywołanie letsThrow() będzie wykrywany jako nie żyje.

Można to wymusić, sprawdzając przypadki, w których zwracana wartość letsThrow() nie jest używana przy użyciu narzędzia do analizy statycznej. Na przykład Google's errorprone has a checker for the @CheckReturnValue annotation, który zapewnia, że ​​używasz wyniku.

(W przypadku wersji dla biednych, wyszukaj wyrażenie regularne ^\s*letsThrow();).