Spróbuj ... złapać go wewnątrz czy na zewnątrz pętli?

Wydajność:

Nie ma absolutnie żadnej różnicy w wydajności w miejscu, w którym znajdują się struktury try/catch. Wewnętrznie są one zaimplementowane jako tabela zakresu kodu w strukturze, która jest tworzona podczas wywoływania metody. Podczas wykonywania metody, struktury try/catch są całkowicie poza obrazem, chyba że wystąpi rzut, a następnie lokalizacja błędu jest porównywana z tabelą.

Oto odniesienie: http://www.javaworld.com/javaworld/jw-01-1997/jw-01-hood.html

Tabela jest opisana w połowie drogi w dół.

Wydajność : Jak Jeffrey powiedział w swojej odpowiedzi, w Javie to nie robi wielkiej różnicy.

Ogólnie , dla czytelności kodu, wybór miejsca przechwycenia wyjątku zależy od tego, czy chcesz, aby pętla nadal przetwarzała, czy nie.

W twoim przykładzie powróciłeś po złapaniu wyjątku. W takim razie, chciałbym umieścić spróbować / złapać wokół pętli. Jeśli po prostu chcesz złapać złą wartość, ale kontynuuj przetwarzanie, włóż ją do środka.

Trzeci sposób: zawsze możesz napisać własną statyczną metodę ParseFloat i mieć do czynienia z obsługą WYJĄTKÓW w tej metodzie, a nie pętli. Czyniąc obsługę wyjątków odizolowanymi do samej pętli!

class Parsing
{
    public static Float MyParseFloat(string inputValue)
    {
        try
        {
            return Float.parseFloat(inputValue);
        }
        catch ( NumberFormatException e )
        {
            return null;
        }
    }

    // ....  your code
    for(int i = 0; i < max; i++) 
    {
        String myString = ...;
        Float myNum = Parsing.MyParseFloat(myString);
        if ( myNum == null ) return;
        myFloats[i] = (float) myNum;
    }
}

Chociaż wydajność może być taka sama, a to, co" wygląda " lepiej, jest bardzo subiektywne, nadal istnieje dość duża różnica w funkcjonalności. Weźmy następujący przykład:

Integer j = 0;
    try {
        while (true) {
            ++j;

            if (j == 20) { throw new Exception(); }
            if (j%4 == 0) { System.out.println(j); }
            if (j == 40) { break; }
        }
    } catch (Exception e) {
        System.out.println("in catch block");
    }

Pętla while znajduje się wewnątrz bloku try catch, zmienna 'j' jest zwiększana do 40, wypisywana, gdy J mod 4 wynosi zero, a wyjątek jest wyrzucany, gdy J trafi 20.

Przed jakimikolwiek szczegółami, tutaj drugi przykład:

Integer i = 0;
    while (true) {
        try {
            ++i;

            if (i == 20) { throw new Exception(); }
            if (i%4 == 0) { System.out.println(i); }
            if (i == 40) { break; }

        } catch (Exception e) { System.out.println("in catch block"); }
    }

Ta sama logika jak powyżej, jedyna różnica polega na tym, że try/catch block jest teraz wewnątrz pętli while.

Oto wyjście (podczas try/catch):

4
8
12 
16
in catch block

I inne wyjście (try/catch in while):

4
8
12
16
in catch block
24
28
32
36
40

Tam masz dość znaczącą różnicę:

Gdy w try / catch wyłamuje się z pętli

Try / catch in while keeps the loop active

Zgadzam się ze wszystkimi postami o wydajności i czytelności. Są jednak przypadki, w których to naprawdę ma znaczenie. Kilka innych osób wspomniało o tym, ale łatwiej byłoby to zobaczyć na przykładach.

Rozważmy ten nieco zmodyfikowany przykład:

public static void main(String[] args) {
    String[] myNumberStrings = new String[] {"1.2345", "asdf", "2.3456"};
    ArrayList asNumbers = parseAll(myNumberStrings);
}

public static ArrayList parseAll(String[] numberStrings){
    ArrayList myFloats = new ArrayList();

    for(int i = 0; i < numberStrings.length; i++){
        myFloats.add(new Float(numberStrings[i]));
    }
    return myFloats;
}

Jeśli chcesz, aby metoda parseAll() zwracała null, jeśli są jakieś błędy( jak w oryginalnym przykładzie), powinieneś umieścić try / catch Na zewnątrz w następujący sposób:

public static ArrayList parseAll1(String[] numberStrings){
    ArrayList myFloats = new ArrayList();
    try{
        for(int i = 0; i < numberStrings.length; i++){
            myFloats.add(new Float(numberStrings[i]));
        }
    } catch (NumberFormatException nfe){
        //fail on any error
        return null;
    }
    return myFloats;
}

W rzeczywistości, prawdopodobnie powinieneś zwrócić błąd tutaj zamiast null, i ogólnie nie lubię mieć wielu zwrotów, ale masz pomysł.

Z drugiej strony, jeśli chcesz, aby po prostu zignorowała problemy i przeanalizowała wszystkie możliwe ciągi, umieścisz try / catch na wewnętrznej stronie pętli w następujący sposób:

public static ArrayList parseAll2(String[] numberStrings){
    ArrayList myFloats = new ArrayList();

    for(int i = 0; i < numberStrings.length; i++){
        try{
            myFloats.add(new Float(numberStrings[i]));
        } catch (NumberFormatException nfe){
            //don't add just this one
        }
    }

    return myFloats;
}

Jak już wspomniano, wydajność jest taka sama. Jednak doświadczenie użytkownika niekoniecznie jest identyczne. W pierwszym przypadku szybko się nie uda( tj. po pierwszym błędzie), jednak jeśli umieścisz blok try/catch wewnątrz pętli, możesz przechwycić wszystkie błędy, które zostaną utworzone dla danego wywołania metody. Podczas parsowania tablicy wartości z łańcuchów, w których spodziewasz się błędów formatowania, są zdecydowanie przypadki, w których chciałbyś być w stanie przedstawić wszystkie błędy użytkownika, aby nie musieli próbować naprawiać ich jeden po drugim.

Jeśli to wszystko albo nic, to pierwszy format ma sens. Jeśli chcesz być w stanie przetworzyć/zwrócić wszystkie niedziałające elementy, musisz użyć drugiego formularza. To byłyby moje podstawowe kryteria wyboru pomiędzy metodami. Osobiście, jeśli to wszystko albo nic, nie używałbym drugiej formy.

Dopóki jesteś świadomy tego, co musisz osiągnąć w pętli, możesz umieścić try catch poza pętlą. Ale ważne jest, aby zrozumieć, że pętla zakończy się, gdy tylko wystąpi wyjątek i to nie zawsze może być to, czego chcesz. Jest to w rzeczywistości bardzo częsty błąd w oprogramowaniu opartym na Javie. Ludzie muszą przetwarzać wiele elementów, takich jak opróżnianie kolejki, i fałszywie polegać na zewnętrznej instrukcji try/catch obsługującej wszystkie możliwe wyjątki. Mogą też obsługiwać tylko określony wyjątek wewnątrz pętli i nie należy oczekiwać wystąpienia żadnego innego wyjątku. Następnie, jeśli wystąpi wyjątek, który nie jest obsługiwany wewnątrz pętli, pętla zostanie "preemted", kończy się prawdopodobnie przedwcześnie i instrukcja outer catch obsługuje wyjątek.

Jeśli pętla miała za swoją rolę w życiu opróżnić kolejkę, to pętla prawdopodobnie mogłaby się skończyć, zanim kolejka ta została naprawdę opróżniona. Bardzo częsty błąd.

W Twoich przykładach nie ma różnicy funkcjonalnej. Twój pierwszy przykład jest bardziej czytelny.

Powinieneś preferować wersję zewnętrzną niż wewnętrzną. Jest to tylko konkretna wersja reguły, przenieś wszystko poza pętlę, które możesz przenieść poza pętlę. W zależności od kompilatora IL i kompilatora JIT dwie wersje mogą, ale nie muszą, mieć różne charakterystyki wydajności.

W innej notce powinieneś chyba spojrzeć na float.Wypróbuj lub przekonwertuj.ToFloat.

Jeśli umieścisz try / catch wewnątrz pętli, będziesz nadal zapętlać po wyjątku. Jeśli umieścisz go poza pętlą, zatrzymasz się zaraz po wyrzuceniu wyjątku.

Moim zdaniem bloki try/catch są niezbędne do zapewnienia właściwej obsługi wyjątków, ale tworzenie takich bloków ma wpływ na wydajność. Ponieważ pętle zawierają intensywne powtarzalne obliczenia, nie zaleca się umieszczania bloków try/catch wewnątrz pętli. Ponadto wydaje się, że tam, gdzie występuje ten warunek, często jest to" wyjątek "lub" RuntimeException", który jest przechwytywany. Należy unikać przechwytywania RuntimeException w kodzie. Ponownie, jeśli pracujesz w dużej firmie, konieczne jest, aby zapisz ten wyjątek poprawnie lub zatrzymaj wyjątek runtime, aby się wydarzył. Cały punkt tego opisu to PLEASE AVOID USING TRY-CATCH BLOCKS IN LOOPS

Ustawienie specjalnej ramki stosu dla try / catch dodaje dodatkowe koszty, ale JVM może być w stanie wykryć fakt powrotu i zoptymalizować to.

W zależności od liczby iteracji, różnica w wydajności będzie prawdopodobnie znikoma.

Jednak zgadzam się z innymi, że posiadanie go poza pętlą sprawia, że ciało pętli wygląda czystiej.

Jeśli istnieje szansa, że będziesz chciał kontynuować przetwarzanie, a nie zakończyć, jeśli istnieje nieprawidłowy numer, wtedy chcesz, aby Kod był wewnątrz pętli.

Jeśli jest w środku, zyskasz narzut struktury try/catch N razy, w przeciwieństwie do tylko raz na zewnątrz.

Za każdym razem, gdy wywołana jest struktura Try/Catch, dodaje ona narzut do wykonania metody. Wystarczy odrobina pamięci i procesora, aby poradzić sobie ze strukturą. Jeśli uruchamiasz pętlę 100 razy, a dla hipotetycznego dobra, powiedzmy, że koszt to 1 tick za połączenie try/catch, to posiadanie Try / Catch wewnątrz pętli kosztuje 100 kleszcze, w przeciwieństwie do tylko 1 kleszcza, jeśli jest poza pętlą.

Cały punkt WYJĄTKÓW ma na celu zachęcenie do pierwszego stylu: umożliwienie skonsolidowania i obsługi błędów raz, a nie natychmiast na każdym możliwym miejscu błędu.

Włóż to do środka. Możesz kontynuować przetwarzanie (jeśli chcesz) lub możesz rzucić pomocny wyjątek, który informuje Klienta o wartości myString i indeksie tablicy zawierającej złą wartość. Myślę, że NumberFormatException już powie ci złą wartość, ale zasadą jest umieszczenie wszystkich przydatnych danych w wyjątkach, które rzucasz. Zastanów się, co byłoby dla Ciebie interesujące w debuggerze w tym momencie programu.

Rozważmy:

try {
   // parse
} catch (NumberFormatException nfe){
   throw new RuntimeException("Could not parse as a Float: [" + myString + 
                              "] found at index: " + i, nfe);
} 

W czasie potrzebujesz naprawdę docenią wyjątek jak ten z jak najwięcej informacji w nim, jak to możliwe.

Chciałbym dodać własne 0.02c o dwóch konkurencyjnych rozważaniach, patrząc na ogólny problem, gdzie umieścić obsługę wyjątków:

1. "szersza" odpowiedzialność try-catch bloku (tj. poza pętlą w Twoim przypadku) oznacza, że podczas zmiany kodu w późniejszym czasie możesz omyłkowo dodać linię, którą obsługuje twój istniejący catch blok; być może nieumyślnie. W Twoim przypadku jest to mniej prawdopodobne, ponieważ wyraźnie łapiesz NumberFormatException

2. Im "węższa" odpowiedzialność bloku try-catch, tym trudniejsza staje się refaktoryzacja. Szczególnie, gdy (jak w Twoim przypadku) wykonujesz" nielokalną " instrukcję z bloku catch (Instrukcja return null).

To zależy od obsługi awarii. Jeśli chcesz tylko pominąć elementy błędu, spróbuj wewnątrz:

for(int i = 0; i < max; i++) {
    String myString = ...;
    try {
        float myNum = Float.parseFloat(myString);
        myFloats[i] = myNum;
    } catch (NumberFormatException ex) {
        --i;
    }
}

Włożę swoje 0,02 dolara. Czasami trzeba dodać" w końcu " później w kodzie (bo kto pisze swój kod idealnie za pierwszym razem?). W takich przypadkach nagle bardziej sensowne jest mieć try / catch poza pętlą. Na przykład:

try {
    for(int i = 0; i < max; i++) {
        String myString = ...;
        float myNum = Float.parseFloat(myString);
        dbConnection.update("MY_FLOATS","INDEX",i,"VALUE",myNum);
    }
} catch (NumberFormatException ex) {
    return null;
} finally {
    dbConnection.release();  // Always release DB connection, even if transaction fails.
}

Ponieważ Jeśli pojawi się błąd, lub nie, chcesz tylko zwolnić połączenie z bazą danych (lub wybrać swój ulubiony typ innego zasobu...) raz.

Innym aspektem nie wspomnianym powyżej jest fakt, że każdy try-catch ma jakiś Wpływ na stos, co może mieć implikacje dla metod rekurencyjnych.

Jeśli metoda" outer () "wywołuje metodę" inner () "(która może wywoływać się rekurencyjnie), spróbuj zlokalizować try-catch w metodzie" outer ()", jeśli to możliwe. Prosty przykład "stack crash", którego używamy w klasie wydajności zawodzi przy około 6400 klatkach, gdy try-catch jest w metodzie wewnętrznej, i przy około 11600, gdy jest w metoda zewnętrzna.

W świecie rzeczywistym może to być problem, jeśli używasz wzorca złożonego i masz duże, złożone struktury zagnieżdżone.

Jeśli chcesz wyłapać wyjątki dla każdej iteracji lub sprawdzić, w jakim wyjątku iteracji jest wyrzucany i wyłapać wszystkie wyjątki w iteracji, umieść try...Złap w pętli. Nie spowoduje to przerwania pętli, jeśli wystąpi wyjątek i możesz przechwycić każdy wyjątek w każdej iteracji w całej pętli.

Jeśli chcesz przerwać pętlę i sprawdzić wyjątek po wyrzuceniu, użyj try...Złap z pętli. Spowoduje to przerwanie pętli i wykonanie instrukcji po catch (jeśli any).

Wszystko zależy od twoich potrzeb. Wolę spróbować...przechwyć wewnątrz pętli podczas wdrażania, ponieważ jeśli wystąpi wyjątek, wyniki nie są niejednoznaczne i pętla nie pęknie i nie zostanie wykonana całkowicie.