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

Цитата korvin @ 15.05.15, 15:00

В этом смысл корутин, после вызова они «открепляются» от вызвавшей/создавшей их сущности и живут сами по себе. А планировщик, например, может быть встроен в рантайм и недоступен из языка.

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

Цитата korvin @ 15.05.15, 15:00

2) Нормальный ход. Т.е. исключение просто уйдёт в никуда? Чем это отличается от простого return?

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

Цитата korvin @ 15.05.15, 15:00

3) «И что?» В протоколе HTTP нет исключений, только коды ошибок. Ты (ну или билиотечная функция) получаешь от HTTP-сервера код ошибки, оборачивает его в исключение, ты (уже в своём коде) его отлавливаешь и передаешь дальше по HTTP код ошибки. Создал себе трудность и героически её преодолел, молодец, чё. =)

Ты сам-то понял что сказал в этой фразе? Я имел ввиду http-сервер работающий на корутинах. Пришел http-запрос извне, запускаем корутину для работы с этим запросом, она внезапно сдохла выбросив исключение. http-сервер поймал это исключение обработал его и выдал соответствующую HTTP-ошибку в TCP-сокет. Где тут "трудности"?

Цитата korvin @ 15.05.15, 15:00

4) Молодец какой, а мне в конкуррентном коде на Go ни разу не захотелось использовать panic, например.

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

Цитата korvin @ 15.05.15, 15:00

P.S. Вообще, мы тут сильно отвлекаемся от темы, как бы нас в холивары не перекинули. =)

Уже перекинули, если ты не заметил

Цитата MyNameIsIgor @ 15.05.15, 14:42

В случае акторов, то в том же Erlang есть дереве наблюдения процессов, и мы можем отлавливать ошибки других процессов.

Ага, и с исключениями там тот ещё бардак.

Цитата

There should really be a compiler warning -

** try-catch-after used - this is probably not the right way to do things

Cheers

Цитата korvin @ 15.05.15, 15:18

Ага, и с исключениями там тот ещё бардак.

Ну, грубо говоря, там два механизма - старый и новый. И оба не рекомендуются к использованию В пользу концепции let it crash.

Цитата MyNameIsIgor @ 15.05.15, 15:08

Слона то ты и не заметил

Черт, я пока набирал сообщение, подумал, надо посмотреть, с чего всё началось и вернуться к теме, а ссылок на предыдущие страницы-то нет. Не сразу понял, что за фигня. =)

Добавлено 15.05.15, 15:28

Цитата MyNameIsIgor @ 15.05.15, 15:24

Ну, грубо говоря, там два механизма - старый и новый. И оба не рекомендуются к использованию В пользу концепции let it crash.

Ну как рекомендации по использованию panic в Go. О чём и речь.

Цитата korvin @ 15.05.15, 15:27

Ну как рекомендации по использованию panic в Go. О чём и речь.

Нет, речь о том, что ты спрашивал, кто перехватит исключение из сопрограммы. В Erlang я могу получить сообщение о падении другого процесса и обработать его, не завершая программу. В Go я могу в одной горутине обработать панику другой горутины?

Цитата applegame @ 15.05.15, 15:12

1) Никуда они не открепляются. Всегда кто-то ждет завершения этой корутины, аварйино или нормально. Это может быть планировщик или еще что-нибудь.

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

3) Ты сам-то понял что сказал в этой фразе? Я имел ввиду http-сервер работающий на корутинах. Пришел http-запрос извне, запускаем корутину для работы с этим запросом, она внезапно сдохла выбросив исключение. http-сервер поймал это исключение обработал его и выдал соответствующую HTTP-ошибку в TCP-сокет. Где тут "трудности"?

4) Да, но на основании этого нельзя утверждать, что исключения плохи в конкурентном коде. Я же не утверждаю, что в конкурентном коде нельзя обойтись без исключений.

1) На уровне языка никто не ждёт. Если я запущу долгую корутину, а потом выйду из main, программа тупо завершится. Со всеми корутинами. Чтобы ждать, мне придётся воспользоваться пакетом sync например, или вручную организовать ожидание.

2) Т.е. ошибка прошла незамеченой. Хороший подход. Видимо, BSOD из таких: все наплевали, а результат в итоге «на экран».

3) Каким образом именно HTTP сервер её поймает? Откуда он знает, что это исключение предназначалось ему, а не какой-то другой корутине, которая, например, разруливает запросы к БД? Если у меня две корутины, отлавливающие исключения, которая из них должна поймать это исключение? Если запрос запустил корутину и корректно завершился (т.к. ему пофиг на корутину, она просто в фоне должна что-то делать), соединение с клиентом закрылось, куда HTTP сервер отправит ошибку?

4) Там по ссылке подробней.

Добавлено 15.05.15, 15:50

Цитата MyNameIsIgor @ 15.05.15, 15:31

В Erlang я могу получить сообщение о падении другого процесса и обработать его, не завершая программу. В Go я могу в одной горутине обработать панику другой горутины?

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

Цитата korvin @ 15.05.15, 15:38

Но, раз в Эрланге можно, если у меня два процесса мониторят один, какой из них перехватит исключение? Как вообще передаются исключения?

Получат оба. И не совсем исключение, а сигнал о завершении, исключения используются (вернее, не рекомендуются к использованию) внутри процесса. Лучше прочитай здесь.

Цитата OpenGL @ 15.05.15, 14:39

Цитата Qraizer @ 15.05.15, 13:58

Теперь ещё и злостный оффтоп.

Скрытый текст

Мы уже морально были готовы к переносу

Скрытый текст

Т.е. никто даже не сомневался, что банки не будет. А я всё-таки раздумывал, ибо калечить тему не хотелось.

Цитата MyNameIsIgor @ 15.05.15, 16:01

Получат оба. И не совсем исключение, а сигнал о завершении.

Таки чем это отличается от отправки сообщения по каналу?

Цитата korvin @ 15.05.15, 16:14

Таки чем это отличается от отправки сообщения по каналу?

Таки ничем. Но разговор то у нас об обработке падения сопрограммы. Ты задавал вопрос - кто же будет обрабатывать? Вот я и отвечаю - найдётся кто. В чём проблема то?

Цитата korvin @ 15.05.15, 15:38

На уровне языка никто не ждёт. Если я запущу долгую корутину, а потом выйду из main, программа тупо завершится. Со всеми корутинами. Чтобы ждать, мне придётся воспользоваться пакетом sync например, или вручную организовать ожидание.

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

Цитата korvin @ 15.05.15, 15:38

2) Т.е. ошибка прошла незамеченой. Хороший подход. Видимо, BSOD из таких: все наплевали, а результат в итоге «на экран».

Да, плохой подход. Но это если все через жопу написано. В нормальных системах планировщик перехватит такое исключение. Никаких BSODов, приложение продолжит работать.

Цитата korvin @ 15.05.15, 15:38

Каким образом именно HTTP сервер её поймает? Откуда он знает, что это исключение предназначалось ему, а не какой-то другой корутине, которая, например, разруливает запросы к БД?

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

Цитата korvin @ 15.05.15, 15:38

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

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

Цитата korvin @ 15.05.15, 15:38

Если запрос запустил корутину и корректно завершился (т.к. ему пофиг на корутину, она просто в фоне должна что-то делать), соединение с клиентом закрылось, куда HTTP сервер отправит ошибку?

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

P.S. У меня создается впечатление, что мы с тобой о разных сущностях говорим.

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

Цитата OpenGL @ 15.05.15, 14:39

ЕМНИП, только в дебаге.

Ну да, наверное. Цель же - указать на неправильное использование.

Цитата OpenGL @ 15.05.15, 14:39

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

Дык, никто не мешает писать код не задумываясь об "exception safety". И С++ не предоставляет не предоставляет никаких средств, чтобы указать на это, кроме документирования. Qt тут ничем не хуже и не лучше той же стандартной библиотеки - если сырые указатели в вектор положить, то память легко утечь может.
Имхо, как раз всё укладывается в "ограничения языка".

Цитата MyNameIsIgor @ 15.05.15, 16:18

Таки ничем. Но разговор то у нас об обработке падения сопрограммы. Ты задавал вопрос - кто же будет обрабатывать? Вот я и отвечаю - найдётся кто. В чём проблема то?

В том, что этот кто может быть не один? И может оказаться неизвестно где? Как отладчику с этим работать?

Цитата korvin @ 15.05.15, 16:58

Цитата MyNameIsIgor @ 15.05.15, 16:18

Таки ничем. Но разговор то у нас об обработке падения сопрограммы. Ты задавал вопрос - кто же будет обрабатывать? Вот я и отвечаю - найдётся кто. В чём проблема то?

В том, что этот кто может быть не один? И может оказаться неизвестно где? Как отладчику с этим работать?

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

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