Круто или глупо? Поймать (Исключение [NamingException, CreateException] e) - PullRequest
4 голосов
/ 04 декабря 2008

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

try{

        // do stuff... throws JMS, Create and NamingException

} catch (NamingException e) {

        log1(e);
    rollback();
        doSomething(e)
} catch (CreateException e) {

        log1(e);
    rollback();
        doSomething(e)
}

Где JMSException будет обрабатываться где-то в стеке.

Было бы просто написать:

try{

        // do stuff... throws JMS, Create and NamingException
} catch Exception[NamingException, CreateException] e) {

        log1(e);
    rollback();
        doSomething(e)
}

вместо использования вспомогательного метода:

try{

        // do stuff... throws JMS, Create and NamingException
} catch (NamingException e) {

        helper_handleError1(e)
} catch (CreateException e) {

        helper_handleError1(e)
}

Обратите внимание, что я хочу распространить трассировку стека исходной JMSException, и мне не «хочется» создавать новое исключение JMSException с третьим предложением catch:)

Какие-нибудь жесткие? Это экстремальная ситуация, которая только загрязняет синтаксис Java, или просто классная вещь для добавления?

Ответы [ 8 ]

5 голосов
/ 04 декабря 2008

Они рассматривают расширение этого типа для Java 7.

См .: http://tech.puredanger.com/java7#catch

4 голосов
/ 04 декабря 2008

Пока мы создаем синтаксис, вот как я бы хотел это видеть:

try
{
   // do stuff ...
}
catch (NamingException e)
catch (CreateException e)
{
   log1(e);
   rollback();
   doSoemthing(e);
}

Аналогично падению оператора switch или блока C # using. Конечно, здесь есть проблема с переменной e, объявленной дважды, но я думаю, что-то может быть решено.

0 голосов
/ 04 декабря 2008

Почему не просто

try
{
   // do stuff... throws JMS, Create and NamingException
}  catch (JMSException e) 
{   
   if (e instanceof CreateException || e instanceof NamingExcption)
   {    
     log1(e);
     rollback();
     doSomething(e);
   }
   else
     throw e;
}
0 голосов
/ 04 декабря 2008

Еще один способ сделать.

Преобразование исключения низкого уровня в собственное исключение высокого уровня и его обработку.

try{
    try{
        // do stuff... throws JMS, Create and NamingException
    } catch (NamingException e) {
            throw new MyException(e);
    } catch (CreateException e) {
            throw new MyException(e);
    }
} catch (MyException e) {
    // something on e or e.getCause();
}
0 голосов
/ 04 декабря 2008

На первом месте,

} catch Exception[NamingException, CreateException] e) {

не хватает символа '('.

Во-вторых, почему «Exception [NamingException, CreateException] e», а не просто «[NamingException, CreateException] e»?

Идея может быть хорошей, но требует некоторой полировки. Например, предположим, что я объявляю класс «MyException» с функцией «doYellow ()» и класс «OtherException» с функцией «doYellow ()». Будет ли разрешена такая функция (учитывая, что в суперклассе нет функции doYellow ()). Если это так, будет ли разрешено, если doYellow () было объявлено только для одного из них? Для этого и есть «Исключение» перед [] символами? Также предположим, что есть эта декларация:

void doYellow(NamingException e);
void doYellow(CreateException e);

(обратите внимание, что это разные функции) будет ли разрешено называться?

Вы действительно должны предоставить дополнительную информацию. Однако в некоторых случаях это может быть полезно (это не редкость)

0 голосов
/ 04 декабря 2008

Попробуйте это:

try {
  ...
} catch ( Exception e) {
  if typeof(e) not in ('MyException', 'SpecialException') {
    throw e
  }
  doSomething()
}

(псевдокод)

0 голосов
/ 04 декабря 2008

Я предлагаю использовать идиому «Выполнить вокруг».

0 голосов
/ 04 декабря 2008

Хотелось бы, чтобы можно было выполнить сопоставление с образцом для типа исключения в качестве синтаксического объявления. Что-то вроде

try {
  ...
} catch ((IOException && !FileNotFoundException) || IllegalArgumentException ) {
  ... handle it
}
...