Czy umieszczenie bloku try-catch wpływa na wydajność?

Question

Czy umieszczenie bloku try-catch wpływa na wydajność?

Przykład 1: try-haczyk blok wewnątrz od czas pętli

while (true) { 
    try { 
     // ... read from a file 
    } catch (EOFException e) { 
     break; 
    } 
} 

Przykład 2: try-haczyk blok otacza czas pętli

try { 
    while (true) { 
     // ... read from a file 
    } 
} catch (EOFException e) { 
    // :P 
} 

Logicznie rzecz biorąc, są dwa przykłady są równoważne, ale które preferuję?

Answer 1

Niezależnie od tego, na jaki koszt może się składać try-catch, nie ma znaczenia, ale w pierwszym przypadku zwracam większą uwagę na to, że wprowadza w błąd: łapiesz wyjątek, tylko po to, aby przerwać pętlę. Wybrałbym rozwiązanie 2 tylko dlatego, że jest zgodne z intencją. I unikasz w ten sposób jakiegokolwiek obciążenia.

Answer 2

Czy możesz wyjść poza czasem? Nie sądzę, aby twoje założenie, że 2 są równoważne, jest prawdziwe.

Moja intuicja podpowiada mi, że próba/catch poza pętlą jest lepsza. Jeśli istnieje wpływ kodu bajtowego, pisząc próbę/catch, mniej utworzone jest lepsze. Jeśli nie ma wpływu, chyba że wystąpi wyjątek, to nie ma znaczenia. Nie widzę żadnych okoliczności, w których posiadanie try/catch w środku byłoby lepsze.

mogę się mylić ...

Answer 3

Should java try blocks be scoped as tightly as possible?

To daje znacznie lepszą odpowiedź niż mogłem. Krótko mówiąc, dodają tylko pozycję do tabeli, która jest sprawdzana, gdy są zgłaszane wyjątki, więc jeśli nie zostanie zgłoszony wyjątek, nie mają one wpływu na wydajność. Najlepiej po prostu umieścić go tam, gdzie najlepiej jest spróbować odzyskać, jeśli możesz. Jeśli nie, to gdziekolwiek jest przydatny lub ma sens. Chociaż z przerwą poza pętlą, nie sądzę, że drugi jest ważny.

Answer 4

Drugi przykład (blok try-catch otaczający kod) jest szybszy i bardziej przejrzysty.

Answer 5

Umieszczenie twojego try-catch nie ma żadnego wpływu na wydajność twojej aplikacji. Nawet gdyby tak było, byłoby to zupełnie nieistotne, to nie jest miejsce, w którym chcesz kierować swoją energią. Wdrożyć na podstawie potrzeby, a następnie zoptymalizować. Nie mikro-optymalizacji.