LINUX.ORG.RU

exceptions сделать что-то в каждом из них

 ,


0

1

допустип есть такой код:

try
{
   doThing();
}
catch (const exceptionA& a)
{
   handleA();
}
catch (const exceptionB& b)
{
   handleB();
}
...

Как выполнить handleCommon() и для А и для В? Ну т.е. можно продублировать везде, что я сейчас и собираюсь сделать, просто хотел узнать, есть ли другой способ.

★★★★★

В яве есть finally, в плюсах нет. А зачем вам нужно это? Может можно поправить архитектуру, заюзать raii?

andreyu ★★★★★
()
Ответ на: комментарий от next_time

Это поймются те, для которых нет catch. А мне нужно для всех.

UVV ★★★★★
() автор топика
Ответ на: комментарий от next_time

Это если предыдущие catch() не перехватили исключение. А в задаче ТС, как я понял, нужно поймать exceptionA или exceptionB, а после сделать finally.

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

Да, вот я помню про finally. В плюсах такого нет?

UVV ★★★★★
() автор топика
Ответ на: комментарий от UVV

На время ожидания курсор нужно поменять.

Тут как раз именно RAII подойдет.

asaw ★★★★★
()
Ответ на: комментарий от UVV

На время ожидания курсор нужно поменять.

Логика на эксепшенах? Нет пути. Грызи дальше

Deleted
()

Скорее всего, тебе следует пересмотреть архитектуру в сторону использования RAII. finally и его аналоги - мусор в коде.

anonymous
()
CL-USER> (handler-case
             (handler-bind ((error
                              #'(lambda (c)
                                  (format t "~&handleCommon: ~S~%" c))))
               (progn
                 (format t "doThing~%")
                 (format t "doAnotherThing~%")))
           (division-by-zero ()
             (format t "handleA~%"))
           (parse-error ()
             (format t "handleB~%")))
doThing
doAnotherThing
NIL
CL-USER> (handler-case
             (handler-bind ((error
                              #'(lambda (c)
                                  (format t "~&handleCommon: ~S~%" c))))
               (progn
                 (format t "doThing~%")
                 (/ 7 0)
                 (format t "doAnotherThing~%")))
           (division-by-zero ()
             (format t "handleA~%"))
           (parse-error ()
             (format t "handleB~%")))
doThing
handleCommon: #<DIVISION-BY-ZERO 402021DCBB>
handleA
NIL
CL-USER> (handler-case
             (handler-bind ((error
                              #'(lambda (c)
                                  (format t "~&handleCommon: ~S~%" c))))
               (progn
                 (format t "doThing~%")
                 (parse-integer "A")
                 (format t "doAnotherThing~%")))
           (division-by-zero ()
             (format t "handleA~%"))
           (parse-error ()
             (format t "handleB~%")))
doThing
handleCommon: #<CONDITIONS::SIMPLE-PARSE-ERROR 40200FC453>
handleB
NIL
Oxdeadbeef ★★★
()

Сделай по-колхозному: просто продублируй вызов handleCommon().

Делать что-либо архитектурно-правильным нужно если обратишься к этому коду дважды. Написал и забыл, сэкономив время.

С другой стороны если у тебя десяток подобных обработок, может сделать базовый класс, который займётся обработкой общей части, а наследники своей специализированной частью.

necromant ★★
()

Так вообще можно обработчики сделать функторами, а в их реализации заюзать паттерн Non-Virtual Interface, но для такой маленькой фигни это того не стоит.

asaw ★★★★★
()
Ответ на: комментарий от UVV

Т.е. чтобы курсор поменять, ещё один класс городить.. Как-то не прикалывает )

Ну дело ваше.

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

Ну так сделать

try
{
try
{
   doThing();
}
catch (const exceptionA& a)
{
   handleA();
   throw a;
}
catch (const exceptionB& b)
{
   handleB();
   throw a;
}
}
catch(...)
{
   handleCommon();
}

если нужно 100500 строк таких написать, то далее Ctrl+H и меняем «} catch » на «throw a; } catch»

next_time ★★★★★
()
BOOST_SCOPE_EXIT() {
    handleCommon();
} BOOST_SCOPE_EXIT_END;
doThing();

Забудь про finally и прочий мусор.

anonymous
()
Ответ на: комментарий от andreyu

в данном случае мы 1)мгновенно решаем проблему 2)оставляем легко читаемый и модифицируемый код. костыль ли это?

next_time ★★★★★
()
#include <functional>
#include <memory>
#include <cstdio>

void handleCommon() {puts("common");}

int main()
{
  try {
    std::unique_ptr <void, std::function <void(void *)> > recoil ((void *)1, [] (void *) {handleCommon();});
    throw 1;
    recoil.release();
  } catch (int i) {
    puts("int catched");
  }
}
anonymous
()
Ответ на: комментарий от next_time

какова задача таково и решение

Задача вполне нормальная и не такая и редкая. И (гораздо) более удачные решения имеются: BOOST_SCOPE_EXIT, RAII, своя функция удаления для unique_ptr/shared_ptr.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

из оп-поста следует, что общая обработка нужна только при возникновении исключения. ни один из предложенных методов это не умеет.

anonymous
()
Ответ на: комментарий от next_time

в данном случае мы
1)мгновенно решаем проблему

А rtti - это недостаточно быстро?

2)оставляем легко читаемый и модифицируемый код.

Не стоит на людях говорить, что это легко читаемый и модифицируемый код.

костыль ли это?

Да.

andreyu ★★★★★
()
Ответ на: комментарий от anonymous

И что с того? Пусть развивается. Ты то наверное родился сразу с полными знаниями, и только от сиськи мамкиной оторвался — сразу работать пошел. И наврное написал уже к настоящему времени сто тыщ шедевральных маложрущих и не текущих приложений для опенсроца. Давай показывай или молчи в тряпочку — CODEORGTFO!

deep-purple ★★★★★
()
Ответ на: комментарий от andreyu

А rtti - это недостаточно быстро?

rtti надо было сразу применять, архитектуру приложения ради 2-х строчек менять, это как-то

Не стоит на людях говорить, что это легко читаемый и модифицируемый код.

почему? люди, которые не могут легко прочесть и модифицировать этот код всё равно не программисты

next_time ★★★★★
()
Ответ на: комментарий от next_time

rtti надо было сразу применять, архитектуру приложения ради 2-х строчек менять, это как-то

Ну да, лучше продолжать городить костыли. Рефакторинг для слабаков :)

почему? люди, которые не могут легко прочесть и модифицировать этот код всё равно не программисты

Так вы за рефакторинг или против?

andreyu ★★★★★
()
Ответ на: комментарий от next_time

алсо, вообще-то, rtii — это очень медленно

Я там оговорился, речь была о raii. Ясно, что rtti - это еще тот тормоз, да и не везде он есть.

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

за, но рефакторинг не всегда возможен. типичный пример — написанный не вами проект с костылями. мы же не знаем как там у ТС.

next_time ★★★★★
()
Ответ на: комментарий от next_time

типичный пример — написанный не вами проект с костылями. мы же не знаем как там у ТС.

В этом типичном примере рефакторинг в виде raii будет хорошим решением. Если понадобится дальнейший рефакторинг, то он будет проще из-за меньшего количества костылей.

andreyu ★★★★★
()
Ответ на: комментарий от x11hater

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

Oxdeadbeef ★★★
()
Ответ на: комментарий от andreyu

Ясно, что rtti - это еще тот тормоз

«тот еще» это какой? И по сравнению с чем тормоз? И насколько тормоз? Вот эта сказка про то что «тормозииит» это сказка 99 года.. Сейчас RTTI тебе код свернет намного правильнее и быстрее, чем костыли, которые ты вместо него нарисуешь. яснопонятно, что везде совать его суть плохая архитектура и что динамик касты и type_info требуют каких-то движений, но штука иногда крайне полезная и годная и порой с ней намного лучше, чем с костылями.

anonymous
()
Ответ на: комментарий от anonymous

«тот еще» это какой? И по сравнению с чем тормоз? И насколько тормоз?

Это серьезный тормоз, но погроммистам из энтерпрайза это не понять.

andreyu ★★★★★
()

А если сделать вложенный try catch? Первым все поймать, переотправить и ловить нужные. Но это костыль.

Gorthauer ★★★★★
()
Ответ на: комментарий от DarkEld3r

это как бы удочка, а не рыба

понимать как работают исключения не помешает, да

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.