Легальный около Цэ++ шный холивар

Цитата applegame @ 15.05.15, 16:20

1) В этом случае никто не ждет, но это бессмысленный случай. Зачем запускать корутину, чтобы не дожидаясь ее просто выйти из main?

2) Все просто, HTTP-сервер создал корутину и выполняет в ней пользовательский обработчик запроса. Этот пользовательский обработчик завернут в try/catch (в HTTP сервере), все исключения произошедшие в нем будут пойманы и обработаны. Про корутину разруливающую запросы к БД не совсем понял. Если пользовательский обработчик создал еще какие-то корутины и не обработал их исключения, то они упадут и исключения попадут уже не к HTTP-серверу, а выше - к планировщику.

3) Исключения бросают из вызываемых функций, очевидно что тут нет понятия "должна", исключения "может" ловить только та корутина, которая эту функцию запустила (прямо или вложенно через другие функции). Исключение либо ловится на каком либо уровне внутри корутины либо вылезает за ее пределы корутины к планировщику.

4) Зачем HTTP-серверу отправлять ошибку, если обработчик запросов завершился корректно? Отправит клиенту 200 Ok. А фоновая корутина будет работать сама по себе, а ее исключения ловятся либо ей самой либо опять же планировщиком.

1) Это для примера того, что выполнение корутины не зависит от корутины, породившей её.

2) В этой корутине я создал другую корутину, выполняющую фоновый бекап, например, и вернул код 200 или какой там HTTP OK, чтобы клиент не ждал 100500 часов завершения бэкапа и вообще получения ответа, а увидел, что задание запущено.

При

func foo() {
  try {
    doSomething()
  } catch (err) {
    handleError(err)
  }
}

foo ждёт завершения doSomething или выброса её исключения. При

func foo() {
  try {
    go doSomething()
  } catch (err)
    handleError(err)
  }
}

foo не может ждать, она запустила горутину и завершилась. В этом смысл корутин, чтобы не ждать. Иначе второй код ничем не отличался бы от первого.

3) Да речь не об этом. Речь о выбросе исключения из самой корутины. См. пункт 2.

4) И дальше что? Планировщик только распределяет выполнение инструкций, ну, допустим, он поймал исключение, как ты сообщишь клиенту об этом, если он давно отвалился. Может, он вообще больше никогда не подключится. Как вообще должна выглядеть синтаксически обработка исключений от корутин? Вот см. пункт 2. Как должна работать процедура foo?

Добавлено 15.05.15, 17:13

Цитата MyNameIsIgor @ 15.05.15, 17:05

Брать и работать... ЕМНИП, отладчики Erlang позволяют посмотреть кто кого мониторит, кто с кем связан и т.п.
Вообще, это не такая большая проблема по сравнению с завершением программы по панике. Кто-то в используемой мной библиотеке захочет попаниковать. И вот как мне, программисту, это лечить?

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

Цитата korvin @ 15.05.15, 17:11

А городить костыли-обертки из исключений над кривым кодом не нужно

Знаешь, говорил я как-то с одним плюсовиком, написавшим класс мьютекса с assert на случай, если ОС ему мьютекс не создала. Ну, вот утверждает он мне, что надо падать - и всё тут. На мои вопросы вроде "а если я этот мьютекс в плагине использую?" никакого внятного ответа не получил. Так и не убедил кидать исключение.
Я к чему. Падать или нет - это мне решать. У других могут быть другие взгляды. Так же получится и с паникой. Дело не в костылях, а в том, что я хочу решать. И если мне этого не дают, то нафиг-нафиг.

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

korvin

Цитата korvin @ 15.05.15, 17:11

Это для примера того, что выполнение корутины не зависит от корутины, породившей её.

Зависит на самом деле. Корутина сама по себе работать не будет. Это не поток. Но можно ее отдать планировщику и он сам уже будет ее крутить.

Цитата korvin @ 15.05.15, 17:11

2) В этой корутине я создал другую корутину...

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

void foo() {
  ...
  auto fiber = new Fiber(&worker);
  // корутина еще не работает
  auto e = fiber.call(); // корутина крутится пока не вызван yield();
  // сюда управление не дойдет до тех пор
  // пока внутри worker не будет вызван yield();
  ...
}

Цитата korvin @ 15.05.15, 17:11

3) Да речь не об этом. Речь о выбросе исключения из самой корутины. См. пункт 2.

4) И дальше что? Планировщик только распределяет выполнение инструкций, ну, допустим, он поймал исключение, как ты сообщишь клиенту об этом, если он давно отвалился. Может, он вообще больше никогда не подключится. Как вообще должна выглядеть синтаксически обработка исключений от корутин? Вот см. пункт 2. Как должна работать процедура foo?

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

Добавлено 15.05.15, 20:16

Цитата applegame @ 15.05.15, 20:09

Как вообще должна выглядеть синтаксически обработка исключений от корутин?

Для D это выглядит вот так:

auto e = fiber.call();
if(e) {
   writefln("корутина сдохла: %s", e.msg);
}

я надеюсь ты в курсе, что корутины сами по себе не работают? На то они и корутины. Тебе нужно периодически вызывать Fiber.call(), а внутри корутины соответственно Fiber.yield().

Сообщение отредактировано: applegame - 15.05.15, 20:53

Цитата JoeUser @ 15.05.15, 17:09

Народ, а вообще есть хоть какая инфа, почему разработчики Qt напрочь отказались от обработки исключений в своем коде?

Обычно цитируют вот это:

Цитата

When Qt was started exceptions were not available for all the compilers that needed to be supported by Qt. Today we are trying to keep the APIs consistent, so modules that have a history of not using exceptions will generally not get new code using exceptions added.

You will notice exceptions are used in some of the new modules of Qt.

Правда ссылки, которые приводят, уже протухли.

Ну и для "базового апи" это вполне удобно, имхо. А дальше мы уже сами решаем является та или иная ошибка "исключительной ситуацией". Ещё удобнее, конечно, предоставлять по две версии (ну или с перегрузкой) апи, но это, очевидно, больше работы потребует.

Сообщение отредактировано: DarkEld3r - 15.05.15, 20:35

Почитал я про горутины и сдается мне что korvin путает горутины и корутины, а это разные вещи на самом деле. Горутина - это фактически надстройка над корутинами, причем горутины подразумевают наличие планировщика, который, как я понимаю, встроен в Go.
Аналог горутин в vibe.d - это Task:

void foo() {
  Task[] pool;
  // стартуем параллельно три таска и пишем их в массив
  iota(3).each!(i =>
    pool ~= runTask({
      // тельце корутины, передача управления другим корутинам в этом потоке
      // только при блокирующих операциях (I/O, мьютексы и прочая байда)
      ...
      veryLongRequest(i);
      ...
    })
  );
  // ждем пока все таски не выполнятся
  pool.each!(t => t.join);
}

Сообщение отредактировано: applegame - 15.05.15, 20:51

Я тут по нужде написал на java програмулину.
Ну, что то она там из оракла выдергивает, и т.п. JDBC и все такое.
Написал быстро и был доволен. До поры. Пока мне не пришлось обработать более 1200 селектов за сессию. А далье меня обругали - что слишком много курсоров в сессии.
ОКАЗЫВАЕТСЯ РЕКОРДСЕТЫ НАДО ЗАКРЫВАТЬ ВРУЧНУЮ!
Фу!! Каменный век!
я в C++ не помню когда последний раз использовал close() или delete вручную, все закрывается само - в деструкторе. Авто-объекты рулят. И кто после этого язык с автоматической сборкой мусора??? неужели JAVA???

Сообщение отредактировано: Бобёр - 02.06.15, 13:50

Автоматическая и автоматизированная – разные вещи. И – да: я за вторую.

Цитата Бобёр @ 02.06.15, 13:45

Я тут по нужде написал на java програмулину.
Ну, что то она там из оракла выдергивает, и т.п. JDBC и все такое.
Написал быстро и был доволен. До поры. Пока мне не пришлось обработать более 1200 селектов за сессию. А далье меня обругали - что слишком много курсоров в сессии.
ОКАЗЫВАЕТСЯ РЕКОРДСЕТЫ НАДО ЗАКРЫВАТЬ ВРУЧНУЮ!
Фу!! Каменный век!
я в C++ не помню когда последний раз использовал close() или delete вручную, все закрывается само - в деструкторе. Авто-объекты рулят. И кто после этого язык с автоматической сборкой мусора??? неужели JAVA???

А с try-with-resources эта штука не работает?

Ну, очевидно же, да? что я close() в секцию finally записал.
А есть ли какой то аналог C#-ого using или питонячьего with в java?

Цитата Бобёр @ 03.06.15, 06:43

Ну, очевидно же, да? что я close() в секцию finally записал.
А есть ли какой то аналог C#-ого using или питонячьего with в java?

Так я про этот аналог и говорил в прошлом посте
The try-with-resources Statement

А.. вон оно что, Михалыч
а оно закрывает, да? будем юзать.

Цитата Бобёр @ 02.06.15, 13:45

все закрывается само - в деструкторе

так деструкторов-то нет! отсюда вся печаль

Ну так какие могут быть деструкторы в случае сборки мусора? Только финализаторы.

ну, финализатор это совсем не то. Мягко говоря , нежно выражаясь