Почему скобки необходимы в блоке catch в Java?

Question

В Java, если мы должны выполнить только один оператор после if или for, скобки не нужны. Мы можем написать:

if(condition)
  executeSingleStatement();

или

for(init;condition;incr)
  executeSingleStatement();

Но в случае с блоком catch мы не можем опустить скобки? Почему это невозможно?

catch(Exception e)
   e.printStackTrace();

Потому что в большинстве случаев мы У меня есть только один оператор в блоке catch, который либо e.printStackTrace() во время тестирования, либо оператор записи.

Answer 1

Найдите учебник по построению компилятора и посмотрите на неопределённость.

Учитывая, что в Java и большинстве других языков с ужасным синтаксисом, пробел лежит.Как вы интерпретируете:

try
try
stuff();
catch (FooException exc)
handle(exc);
catch (BarException exc)
handle(exc);
catch (BazException exc)
handle(exc);

Является ли это:

try {
    try {
        stuff();
    } catch (FooException exc) {
        handle(exc);
    } catch (BarException exc) {
        handle(exc);
    }
} catch (BazException exc) {
    handle(exc);
}

Или:

try {
    try {
        stuff();
    } catch (FooException exc) {
        handle(exc);
    }
} catch (BarException exc) {
    handle(exc);
} catch (BazException exc) {
    handle(exc);
}

Устраненная неопределенность решается путем сопоставления elseс самой внутренней if.Мы хотим добавить более сложное усложнение, чтобы справиться с этим плохим стилем?Нет.

Answer 2

Это не проблема возможного или невозможного. Это просто решение по языку (синтаксису).

Существует несколько реализаций синтаксического анализатора языка Java. Можно изменить источник парсера менее чем за день и разрешить операторы catch без скобок.

http://www.google.com/search?q=java+parser

Также обратите внимание грамматика языка Java .

Answer 3

Я не уверен, почему Java не позволяет этого, но, вообще говоря, лучше использовать скобки, даже если есть только одно утверждение. Это облегчает чтение и расширение.

Вот еще один вопрос, касающийся использования скобок: Нужны ли фигурные скобки в однострочных операторах JavaScript?

Answer 4

Из Java Language Spec 3.0 - Если вы посмотрите на главу 14, она говорит о блоках и утверждениях.Блоки идентифицируются {и} и содержат много операторов.Try / catch / finally - это блоки, которые согласно спецификации языка должны быть сгруппированы в {}.

Answer 5

Я также не вижу никакой выгоды в написании бесполезного кода, и я также не понимаю, как больше текста может быть проще.

Я помогаю себе, записывая однострочные уловы ровно в одну строку:

catch (InvalidArgumentException e) { die (e.getMessage()); }
catch (Exception e)                { die (e); }

Для меня это самый читаемый способ. Это только загромождается, когда люди пытаются написать полные романы в имена исключений.

catch (CanNotPayAttentionToThatManBehindTheCurtainThrowableRuntimeExceptionWithMessageAndCouseContainItselfAnotherCourseAndMessage e) ...

Answer 6

Вероятно, унаследовано от C ++.Понятия не имею, почему C ++ сделал это.Смотрите мои мысли здесь: https://stackoverflow.com/questions/6254595/how-do-you-use-the-return/6255489#6255489

Стоит также отметить, что {} упрощает грамматику, то есть облегчает жизнь дизайнера языка.Выражение if является хорошим примером - удобство, которое вам нравится, не обходится дешево.

Из-за такой неоднозначности, как

if(c1) if(c2) A; else B;

interpretation 1 
if(c1)
    if(c2) 
        A;
    else 
        B;

interpretation 2 
if(c1)
    if(c2) 
        A;
else 
    B;

Грамматика if должна быть настроена для устранения этой неоднозначности.Предположим, что вместо произвольного statement требуется block, грамматика будет намного проще из-за присутствия {}.

Так что они, вероятно, просто ленивые.

Answer 7

Я бы сказал, что «в большинстве случаев» вы должны делать больше, чем просто печатать или регистрировать трассировку стека. Это означает, что вы глотаете исключение, которое обычно не является хорошей практикой. По крайней мере, если вы не можете корректно восстановиться после исключения, вы должны войти в систему и перебросить его в случае, если код может быть выше стека.

Тем не менее, я не думаю, что на самом деле есть ответ на ваш вопрос, кроме "просто как они его разработали".