Dlaczego w try-catch potrzebne są nawiasy?

W różnych językach (przynajmniej Java, myślisz również C #?) Możesz robić takie rzeczy

if( condition )
    singleStatement;

while( condition )
    singleStatement;

for( var; condition; increment )
    singleStatement;

Więc kiedy mam tylko jedną instrukcję, nie muszę dodawać nowego zakresu { }. Dlaczego nie mogę tego zrobić za pomocą try-catch?

try
    singleStatement;
catch(Exception e)
    singleStatement;

Czy jest coś specjalnego w try-catch, która zawsze wymaga posiadania nowego zakresu lub czegoś takiego? A jeśli tak, to czy kompilator nie może tego naprawić?

IMO, są zawarte w Javie i C # głównie dlatego, że już istniały w C ++. Prawdziwe pytanie brzmi zatem, dlaczego C ++ jest w ten sposób. Zgodnie z projektem i ewolucją C ++ (§ 16.3):

Słowo trykluczowe jest całkowicie zbędne, podobnie jak { }nawiasy klamrowe, chyba że w instrukcji try-block lub module obsługi znajduje się wiele instrukcji. Na przykład zezwolenie na:

int f()
{
    return g() catch(xxii) { // not C++
        error("G() goofed: xxii");
        return 22;
    };
}

Jednak tak trudno mi było wytłumaczyć, że wprowadzono nadmiarowość, aby uratować personel pomocniczy przed zdezorientowanymi użytkownikami.

Edycja: Jeśli chodzi o to, dlaczego byłoby to mylące, myślę, że wystarczy spojrzeć na niepoprawne twierdzenia w odpowiedzi @ Toma Jeffery'ego (a zwłaszcza na liczbę głosów, jakie otrzymało), aby zdać sobie sprawę, że będzie problem. Dla parsera tak naprawdę nie różni się to od dopasowania elses do ifs - brak nawiasów klamrowych do wymuszenia innego grupowania, wszystkie catch klauzule pasowałyby do najnowszej throw. W przypadku tych źle wprowadzonych języków, które go zawierają, finallyklauzule zrobiłyby to samo. Z punktu widzenia parsera nie jest to wystarczająco różniące się od obecnej sytuacji, aby zauważyć - w szczególności, ponieważ gramatyka stoi teraz, tak naprawdę nie ma nic do grupowania catchklauzul - nawiasy grupują instrukcje sterowane przezcatch klauzule, a nie same klauzule catch.

Z punktu widzenia pisania parsera różnica jest prawie zbyt mała, aby zauważyć. Jeśli zaczniemy od czegoś takiego:

simple_statement: /* won't try to cover all of this */
                ;

statement: compound_statement
         | simple_statement
         ;

statements: 
          | statements statement
          ;

compound_statement: '{' statements '}'

catch_arg: '(' argument ')'

Wtedy różnica byłaby między:

try_clause: 'try' statement

i:

try_clause: 'try' compound_statement

Podobnie w przypadku klauzul połowowych:

catch_clause: 'catch' catch_arg statement

vs.

catch_clause: 'catch' catch_arg compound_statement

Jednak definicja kompletnego bloku try / catch nie musiałaby się wcale zmieniać. Tak czy inaczej, byłoby to coś takiego:

catch_clauses: 
             | catch_clauses catch_clause
             ;

try_block: try_clause catch_clauses [finally_clause]
         ;

[Tutaj używam [whatever]do wskazania czegoś opcjonalnego i pomijam składnię, finally_clauseponieważ nie sądzę, żeby miało to jakikolwiek związek z pytaniem.]

Nawet jeśli nie starają się przestrzegać wszystkich Yacc-jak tam definicji gramatyki, punkt można podsumować dość łatwo: to ostatnie stwierdzenie (począwszy try_block) to jeden gdzie catchklauzule uzyskać dopasowane z tryklauzul - i pozostaje dokładnie to samo, czy nawiasy klamrowe są wymagane, czy nie.

Powtórzmy / Podsumowując: grupa szelki wraz oświadczenia kontrolowanych przez tych catchs, ale czy nie Group catchs sami. Jako takie, nawiasy klamrowe nie mają absolutnie żadnego wpływu na decyzję, która catchz nich idzie try. Dla parsera / kompilatora zadanie jest równie łatwe (lub trudne) w obu kierunkach. Pomimo tego, @ Toma odpowiedzi (oraz liczby głosów up-to odebrane) zapewnia wystarczającą demonstrację faktu, że taka zmiana would prawie na pewno błąd użytkowników.

W odpowiedzi na pytanie, dlaczego w niektórych konstrukcjach z pojedynczą instrukcją są wymagane nawiasy klamrowe , Eric Lippert napisał:

Istnieje wiele miejsc, w których C # wymaga zbrojonego bloku instrukcji, a nie zezwalania na „nagą” instrukcję. Oni są:

• treść metody, konstruktora, destruktora, akcesorium właściwości, akcesorium zdarzeń lub akcesorium indeksującego.
• blok próby, złapania, wreszcie sprawdzonego, niezaznaczonego lub niebezpiecznego regionu.
• blok instrukcji lambda lub metody anonimowej
• blok instrukcji if lub loop, jeśli blok zawiera bezpośrednio deklarację zmiennej lokalnej. (To znaczy „while (x! = 10) int y = 123;” jest nielegalne; musisz przygotować deklarację).

W każdym z tych przypadków można byłoby wymyślić jednoznaczną gramatykę (lub heurystykę w celu ujednoznacznienia dwuznacznej gramatyki) dla cechy, w której pojedyncze nieskrępowane stwierdzenie jest legalne. Ale jaki byłby sens? W każdej z tych sytuacji oczekuje się wyświetlenia wielu instrukcji; pojedyncze stwierdzenia to rzadki, mało prawdopodobny przypadek. Wydaje się, że naprawdę nie warto sprawiać, by gramatyka była jednoznaczna w tych bardzo mało prawdopodobnych przypadkach.

Innymi słowy, wdrożenie go przez zespół kompilatora kosztowało więcej niż było to uzasadnione, ze względu na marginalną korzyść.

Myślę, że ma to na celu uniknięcie problemów związanych ze stylem. Poniższe byłyby dwuznaczne ...

try
    // Do stuff
try
    // Do  more stuff
catch(MyException1 e1)
    // Handle fist exception
catch(MyException2 e2)
    // So which try does this catch belong to?
finally
    // and who does this finally block belong to?

Może to oznaczać:

try {
   try {

   } catch(Exception e1) {

   } catch(Exception e2) {

   } 
} finally {

} 

Lub...

try {
   try {

   } catch(Exception e1) {

   } 
} catch(Exception e2) {

} finally {

} 

Myślę, że głównym powodem jest to, że niewiele można zrobić w języku C #, który wymagałby bloku try / catch, który jest tylko jedną linią. (Nie mogę teraz wymyślić żadnego z głowy). Możesz mieć ważny punkt pod względem bloku catch, np. Instrukcja jednowierszowa, aby coś zarejestrować, ale pod względem czytelności bardziej sensowne (przynajmniej dla mnie) jest wymaganie {}.