Kompiluje brakującą instrukcję return w metodzie innej niż void

Napotkałem sytuację, w której w metodzie innej niż void brakuje instrukcji return , a kod nadal się kompiluje. Wiem, że instrukcje po pętli while są nieosiągalne (martwy kod) i nigdy nie zostaną wykonane. Ale dlaczego kompilator nawet nie ostrzega o zwrocie czegoś? Albo dlaczego język miałby pozwolić nam na zastosowanie metody nie-void mającej nieskończoną pętlę i niczego nie zwracającej?

public int doNotReturnAnything() {
    while(true) {
        //do something
    }
    //no return statement
}

Jeśli dodam instrukcję break (nawet warunkową) w pętli while, kompilator skarży się na niesławne błędy: Method does not return a valuew Eclipse i Not all code paths return a valueVisual Studio.

public int doNotReturnAnything() {
    while(true) {
        if(mustReturn) break;
        //do something
    }
    //no return statement
}

Dotyczy to zarówno Java, jak i C #.

Dlaczego język miałby pozwalać na stosowanie metody nie-void mającej nieskończoną pętlę i niczego nie zwracającej?

Reguła dla metod nie będących nieważnymi jest taka, że każda zwracana ścieżka kodu musi zwracać wartość , a ta reguła jest spełniona w twoim programie: zero z zerowych ścieżek kodu, które zwracają, zwraca wartość. Reguła nie brzmi: „każda metoda nie void musi mieć ścieżkę kodu, która zwraca”.

Umożliwia to pisanie skrótowych metod takich jak:

IEnumerator IEnumerable.GetEnumerator() 
{ 
    throw new NotImplementedException(); 
}

To metoda nieważna. To musi być non-void metoda w celu zaspokojenia interfejs. Ale niemądre wydaje się uczynienie tej implementacji nielegalną, ponieważ nic nie zwraca.

To, że twoja metoda ma nieosiągalny punkt końcowy z powodu goto(pamiętaj, że while(true)to po prostu przyjemniejszy sposób pisania goto) zamiast throw(co jest inną formą goto) nie ma znaczenia.

Dlaczego kompilator nawet nie ostrzega o zwrocie czegoś?

Ponieważ kompilator nie ma dobrych dowodów na to, że kod jest nieprawidłowy. Ktoś napisał while(true)i wydaje się prawdopodobne, że osoba, która to zrobiła, wiedziała, co robi.

Gdzie mogę przeczytać więcej o analizie osiągalności w C #?

Zobacz moje artykuły na ten temat tutaj:

ATBG: de facto i de jure osiągalność

I możesz również rozważyć przeczytanie specyfikacji C #.

Kompilator Java jest wystarczająco inteligentny, aby znaleźć nieosiągalny kod (kod po whilepętli)

a ponieważ jest nieosiągalny , nie ma sensu dodawać tam returninstrukcji (po whilezakończeniu)

to samo dotyczy warunkowego if

public int get() {
   if(someBoolean) {   
     return 10;
   }
   else {
     return 5;
   }
   // there is no need of say, return 11 here;
}

ponieważ warunek logiczny someBooleanmoże tylko ocenić albo, truealbo falsenie ma potrzeby podawania return jednoznacznie później if-else, ponieważ ten kod jest nieosiągalny , a Java nie narzeka na to.

Kompilator wie, że whilepętla nigdy nie przestanie działać, dlatego metoda nigdy się nie skończy, dlatego returninstrukcja nie jest konieczna.

Biorąc pod uwagę, że twoja pętla działa w sposób ciągły - kompilator wie, że jest to pętla nieskończona - co oznacza, że ​​metoda i tak nigdy nie może wrócić.

Jeśli użyjesz zmiennej - kompilator wymusi regułę:

To się nie skompiluje:

// Define other methods and classes here
public int doNotReturnAnything() {
    var x = true;

    while(x == true) {
        //do something
    }
    //no return statement - won't compile
}

Specyfikacja Java definiuje pojęcie o nazwie Unreachable statements. W twoim kodzie nie możesz mieć nieosiągalnej instrukcji (jest to błąd czasu kompilacji). Po pewnym czasie nie wolno ci nawet mieć instrukcji return (prawda); instrukcja w Javie. while(true);Zestawienie sprawia, że następujące stwierdzenia nieosiągalny z definicji, zatem nie trzeba się returnoświadczenie.

Zauważ, że chociaż problem zatrzymania jest nierozstrzygalny w przypadku ogólnym, definicja nieosiągalnego stwierdzenia jest bardziej rygorystyczna niż zwykłe zatrzymanie. Decyduje o bardzo konkretnych przypadkach, w których program na pewno się nie zatrzymuje. Kompilator teoretycznie nie jest w stanie wykryć wszystkich nieskończonych pętli i nieosiągalnych instrukcji, ale musi wykryć określone przypadki zdefiniowane w specyfikacji (na przykład while(true)przypadek)

Kompilator jest wystarczająco inteligentny, aby dowiedzieć się, że twoja whilepętla jest nieskończona.

Tak więc kompilator nie może myśleć za Ciebie. Nie może zgadnąć, dlaczego napisałeś ten kod. To samo oznacza zwracane wartości metod. Java nie będzie narzekać, jeśli nie zrobisz nic z wartościami zwracanymi przez metodę.

Tak więc, aby odpowiedzieć na twoje pytanie:

Kompilator analizuje kod i po stwierdzeniu, że żadna ścieżka wykonania nie prowadzi do odpadnięcia końca funkcji, kończy się na OK.

Mogą istnieć uzasadnione powody nieskończonej pętli. Na przykład wiele aplikacji korzysta z nieskończonej pętli głównej. Innym przykładem jest serwer WWW, który może bez końca czekać na żądania.

W teorii typów istnieje coś, co nazywa się typem dolnym który jest podklasą każdego innego typu (!) I służy między innymi do wskazania braku zakończenia. (Wyjątki mogą być liczone jako rodzaj nieterminacji - nie kończysz normalną ścieżką).

Tak więc z teoretycznego punktu widzenia, te nie kończące się instrukcje można uznać za zwracające coś typu Bottom, który jest podtypem int, więc otrzymujesz (w pewnym sensie) wartość zwrotną mimo wszystko z perspektywy typu. I jest całkowicie w porządku, że nie ma żadnego sensu, że jeden typ może być podklasą wszystkiego innego, w tym int, ponieważ tak naprawdę nigdy go nie zwraca.

W każdym razie, poprzez teorię typu jawnego lub nie, kompilatory (autorzy kompilatorów) rozpoznają, że proszenie o wartość zwracaną po instrukcji nie kończącej jest głupie: nie ma możliwego przypadku, w którym mogłabyś potrzebować tej wartości. (Może być fajnie, gdy twój kompilator ostrzega cię, gdy wie, że coś się nie skończy, ale wygląda na to, że chcesz coś zwrócić. Ale lepiej to zostawić sprawdzającym styl, a może potrzebujesz podpisu, który: z jakiegoś innego powodu (np. podklasy), ale tak naprawdę chcesz nieterminacji.)

Nie ma sytuacji, w której funkcja może osiągnąć swój koniec bez zwracania odpowiedniej wartości. Dlatego kompilator nie ma na co narzekać.

Visual Studio ma inteligentny silnik wykrywający, czy wpisałeś typ zwracany, a następnie powinien mieć instrukcję return w funkcji / metodzie.

Jak w PHP Twój typ zwrotu jest prawdziwy, jeśli nic nie zwróciłeś. kompilator dostaje 1, jeśli nic nie zostało zwrócone.

Od tego momentu

public int doNotReturnAnything() {
    while(true) {
        //do something
    }
    //no return statement
}

Kompilator wie, że chociaż sama instrukcja ma nieskończony charakter, więc nie należy jej brać pod uwagę. a kompilator php automatycznie się spełni, jeśli napiszesz warunek w wyrażeniu while.

Ale nie w przypadku VS zwróci ci błąd na stosie.

Twoja pętla while będzie działać wiecznie, a zatem nie wyjdzie na zewnątrz; będzie nadal działać. Dlatego zewnętrzna część while {} jest nieosiągalna i nie ma sensu pisać na piśmie, czy nie. Kompilator jest wystarczająco inteligentny, aby dowiedzieć się, która część jest osiągalna, a która nie.

Przykład:

public int xyz(){
    boolean x=true;

    while(x==true){
        // do something  
    }

    // no return statement
}

Powyższy kod nie zostanie skompilowany, ponieważ może się zdarzyć, że wartość zmiennej x zostanie zmodyfikowana w treści pętli while. Dzięki temu można uzyskać dostęp do zewnętrznej części pętli while! Stąd kompilator wygeneruje błąd „nie znaleziono instrukcji return”.

Kompilator nie jest wystarczająco inteligentny (lub raczej leniwy;)), aby dowiedzieć się, czy wartość x zostanie zmodyfikowana, czy nie. Mam nadzieję, że to wszystko wyczyści.

„Dlaczego kompilator nawet nie ostrzega o zwróceniu czegoś? Albo dlaczego język miałby pozwalać na zastosowanie metody innej niż void posiadającej nieskończoną pętlę i niczego nie zwracającej?”.

Ten kod jest ważny również we wszystkich innych językach (prawdopodobnie oprócz Haskell!). Ponieważ pierwsze założenie jest takie, że „celowo” piszemy jakiś kod.

Są też sytuacje, w których ten kod może być całkowicie poprawny, np. Jeśli zamierzasz go używać jako wątku; lub jeśli zwraca a Task<int>, możesz wykonać sprawdzanie błędów na podstawie zwróconej wartości int - której nie należy zwracać.

Mogę się mylić, ale niektóre debugery pozwalają na modyfikację zmiennych. Tutaj, podczas gdy x nie jest modyfikowany przez kod i będzie zoptymalizowany przez JIT, można zmodyfikować x na false, a metoda powinna coś zwrócić (jeśli taka możliwość jest dozwolona przez debugger C #).

Specyfika tego przypadku Java (które prawdopodobnie są bardzo podobne do przypadku C #) dotyczy sposobu, w jaki kompilator Java określa, czy metoda jest w stanie zwrócić.

W szczególności reguły są takie, że metoda z typem zwracanym nie może być w stanie zakończyć się normalnie i zamiast tego musi zawsze zakończyć się nagle (tutaj nagle, wskazując za pomocą instrukcji return lub wyjątku) zgodnie z JLS 8.4.7 .

Jeśli metoda ma zadeklarowany typ zwracany, wówczas błąd kompilacji występuje, jeśli treść metody może się normalnie zakończyć. Innymi słowy, metoda z typem zwracanym musi zwrócić tylko za pomocą instrukcji return, która zapewnia zwrot wartości; nie wolno „zrzucić końca jego ciała” .

Kompilator sprawdza, czy możliwe jest normalne zakończenie na podstawie reguł określonych w JLS 14.21 Nieosiągalne instrukcje ponieważ definiuje również reguły normalnego zakończenia.

W szczególności zasady dotyczące instrukcji nieosiągalnych stanowią szczególny przypadek tylko dla pętli, które mają zdefiniowane truestałe wyrażenie:

Instrukcja while może zakończyć się normalnie, jeśli jest spełniony przynajmniej jeden z następujących warunków:

• Instrukcja while jest osiągalna, a wyrażenie warunkowe nie jest wyrażeniem stałym (§ 15.28) o wartości true.

• Istnieje osiągalna instrukcja break, która wychodzi z instrukcji while.

Jeśli więc whileinstrukcja może się normalnie wypełnić , to konieczne jest podanie poniższej instrukcji return, ponieważ kod jest uznawany za osiągalny, a każda whilepętla bez osiągalnej instrukcji break lub stałejtrue wyrażenia jest uważana za zdolną do ukończenia normalnie.

Reguły te oznaczają, że twoja whileinstrukcja ze stałym prawdziwym wyrażeniem i bez a nigdy niebreak jest uważana za zakończoną normalnie , więc żaden kod poniżej niej nigdy nie jest uważany za osiągalny . Koniec metody znajduje się poniżej pętli, a ponieważ wszystko poniżej pętli jest nieosiągalne, tak samo jest koniec metody, a zatem metoda nie może zakończyć się normalnie (tego szuka kompilator).

if instrukcje, z drugiej strony, nie mają specjalnego wyłączenia dotyczącego stałych wyrażeń, które są zapewnione pętlom.

Porównać:

// I have a compiler error!
public boolean testReturn()
{
    final boolean condition = true;

    if (condition) return true;
}

Z:

// I compile just fine!
public boolean testReturn()
{
    final boolean condition = true;

    while (condition)
    {
        return true;
    }
}

Powód tego rozróżnienia jest dość interesujący i wynika z chęci uwzględnienia flag kompilacji warunkowej, które nie powodują błędów kompilatora (z JLS):

Można oczekiwać, że instrukcja if będzie przetwarzana w następujący sposób:

• Instrukcja if-then może normalnie wypełnić, jeśli spełniony jest przynajmniej jeden z poniższych warunków:

  • Instrukcja if-then jest osiągalna, a wyrażenie warunkowe nie jest wyrażeniem stałym, którego wartość jest prawdziwa.

  • Oświadczenie wtedy może zostać wypełnione normalnie.

  Oświadczenie wtedy jest osiągalne, jeśli oświadczenie if-then jest osiągalne, a wyrażenie warunkowe nie jest wyrażeniem stałym, którego wartość jest fałszywa.

• Instrukcja if-then-else może zostać wykonana normalnie, jeśli instrukcja następnie może zakończyć się normalnie lub instrukcja else może zakończyć się normalnie.

  • Oświadczenie then jest osiągalne, jeśli osiągalne jest wyrażenie if-then-else, a wyrażenie warunkowe nie jest wyrażeniem stałym, którego wartość jest fałszywa.

  • Instrukcja else jest osiągalna, jeśli jest osiągalna instrukcja if-then-else, a wyrażenie warunkowe nie jest wyrażeniem stałym, którego wartość jest prawdziwa.

Takie podejście byłoby spójne z traktowaniem innych struktur kontrolnych. Jednak aby umożliwić wygodne korzystanie z instrukcji if do celów „kompilacji warunkowej”, rzeczywiste reguły są różne.

Na przykład poniższa instrukcja powoduje błąd podczas kompilacji:

while (false) { x=3; }ponieważ oświadczenie x=3;nie jest osiągalne; ale pozornie podobny przypadek:

if (false) { x=3; }nie powoduje błędu czasu kompilacji. Kompilator optymalizujący może zdać sobie sprawę, że instrukcja x=3;nigdy nie zostanie wykonana i może pominąć kod tej instrukcji z wygenerowanego pliku klasy, ale instrukcjax=3; nie jest uważana za „nieosiągalną” w technicznie określonym tutaj znaczeniu.

Uzasadnieniem tego odmiennego traktowania jest umożliwienie programistom zdefiniowania „zmiennych zmiennych”, takich jak:

static final boolean DEBUG = false; a następnie napisz kod taki jak:

if (DEBUG) { x=3; } Chodzi o to, że powinna istnieć możliwość zmiany wartości DEBUG z false na true lub z true na false, a następnie poprawnie skompiluj kod bez żadnych innych zmian w tekście programu.

Dlaczego warunkowa instrukcja break powoduje błąd kompilatora?

Jak podano w regułach osiągalności pętli, pętla while może również zakończyć się normalnie, jeśli zawiera osiągalną instrukcję break. Ponieważ zasady dotyczące osiągalności ifoświadczenia następnie klauzuli nie biorą stan ifpod uwagę w ogóle, taka warunkowa ifoświadczenie jest następnie klauzula jest zawsze uważane za osiągalne.

Jeśli breakjest osiągalny, to kod po pętli jest ponownie uznawany za osiągalny. Ponieważ nie ma dostępnego kodu, który spowodowałby nagłe zakończenie po pętli, metoda jest następnie uważana za zdolną do ukończenia normalnie, a więc kompilator oznacza ją jako błąd.