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

Цитата DarkEld3r @ 15.05.15, 13:32

В Qt вообще нет. Но пользоваться ими не мешают.

Они в документации пишут:

Цитата

Preliminary warning: Exception safety is not feature complete! Common cases should work, but classes might still leak or even crash.

Цитата korvin @ 15.05.15, 13:46

Почему не тянет?

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

Цитата korvin @ 15.05.15, 13:46

Исходники Go открыты, ты можешь переписать его, например, без использования GC, тянет ли это на отказ от возможности вручную управлять освобождением памяти (на уровне языка)?

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

Цитата MyNameIsIgor @ 15.05.15, 13:44

Ну, не знаю... А если мы получаем Maybe, а отдать в функцию дальнейшей обработки нам надо какой-то конкретный тип, то как без условия?

В смысле? Обработкой Maybe-результата и обрывом цепочки выполнения при Nothin или распаковкой при (Just x) занимаются промежуточные функции-операторы, т.е. условно код получается такой:

foo = doSomething1
    <?> doSomething2
    <?> doSomething3
    ...
    <?> doSomethingN

где <?> — полиморфная инфиксная функция, которая и скрывает if'ы и распаковку (Just x)
если ещё и написать соответствующий инстанс тайпкласа Monad, можно использовать do-нотацию без всяких <?>:

foo = do
  doSomething1
  doSomething2
  doSomething3
  ...
  doSomethingN

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

Цитата DarkEld3r @ 15.05.15, 13:52

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

Конечно нет, ты бы SICP почиталкомпилятор вполне себе является инструментом языка.

Цитата OpenGL @ 15.05.15, 13:51

Они в документации пишут:

Ну так там они и описывают когда можно, а когда нет. Выброс исключений в слотах ничем не отличается от исключений в колбеках, по сути. Понятное дело, что из этого ничего хорошего не выйдет. Хотя раньше (подозреваю, что и сейчас, но проверять лень) они подстилали соломку: ловили такие исключения и писали в лог о неправильном использовании.

M

Теперь ещё и злостный оффтоп.
Вы меня убедили, не будем ждать вечера.

Сообщение отредактировано: Qraizer - 15.05.15, 13:59

Цитата korvin @ 15.05.15, 13:56

Конечно нет, ты бы SICP почиталкомпилятор вполне себе является инструментом языка.

С таким же успехом можно и бинарники патчить. Тоже "инструмент".

Причём здесь SICP не понимаю. Одно дело, если нам "из самого языка" доступно изменение поведения через макросы и т.д. И совсем другое, если мы реализуем своё собственное поведение. Если у языка, хотя бы, спека есть, то это уже другой язык будет, по сути.

Цитата korvin @ 15.05.15, 13:56

В смысле? Обработкой Maybe-результата и обрывом цепочки выполнения при Nothin или распаковкой при (Just x) занимаются промежуточные функции-операторы

Ну, я с трудом представляю как подобное сделать для императивщины.

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

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

Да как угодно. Можно передавать исключение наружу, как например передаются исключения из future, а можно тупо перевести корутину в terminated стейт. Как тебе удобней.

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

Цитата MyNameIsIgor @ 15.05.15, 13:47

Либо концепция future/promise.

Я с ней почти не знаком, как она поможет? Чем она удобней CSP/Акторов? Если взять Erlang, там же процессы могут выполняться на разном оборудовании в сети, а если взять ещё более распределённую систему, в которой разные части работаю под разными ОС'ями, написаны на разных языках, с разным рантаймом?

Добавлено 15.05.15, 14:07

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

Ну, я с трудом представляю как подобное сделать для императивщины.

Так в том коде функциональщины как таковой нету, всего лишь параметрический полиморфизм да лямбды, что есть сейчас в любом языке. Да и даже это не обязательно, можно просто синтаксис для этого сделать, try-catch же тоже синтаксическая конструкция. Я тут как-то сделал почти полную копию defer/using для CL макросом и без всякой функциональщины, например.

Добавлено 15.05.15, 14:14

Цитата applegame @ 15.05.15, 14:03

Да как угодно. Можно передавать исключение наружу, как например передаются исключения из future, а можно тупо перевести корутину в terminated стейт. Как тебе удобней.

Наружу чего? Все корутины равноценны, нет никакой «наружи». В main-корутину? Что она будет делать с этим исключением? Если не ошибаюсь, в Джаве есть такой антипаттерн — оборачивать код main в try-catch.

Сообщение отредактировано: korvin - 15.05.15, 14:14

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

Я с ней почти не знаком, как она поможет?

Запомнить исключение, а потом передать его наружу если надо.

Добавлено 15.05.15, 14:31

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

Наружу чего? Все корутины равноценны, нет никакой «наружи»

И что? Всегда есть некая сущность их вызывающая. В асинхронных I/O системах это может быть планировщик этих самых корутин.

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

В main-корутину? Что она будет делать с этим исключением? Если не ошибаюсь, в Джаве есть такой антипаттерн — оборачивать код main в try-catch.

Почему обязательно main? Если корутина сама не обработала исключение, значит можно считать что она просто подохла. Допустим во фреймворке vibe.d в случае подобного поведения файбера если ошибка дойдет до планировщика, то он просто выведет в лог сообщение, что такая-то корутина померла с такой-то ошибкой. На более высоких уровнях можно обрабатывать эти ошибки. Допусти http-сервер в случае издыхания корутины-обработчика запроса, выдает 503 ошибку.
Я очень плотно работаю с конкурентной асинхронной системой построенной на файберах и нахожу исключения архиполезными.

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

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

Я с ней почти не знаком, как она поможет? Чем она удобней CSP/Акторов?

Ну, просто возврат результата. В данном случае результатом будет исключение.

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

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

В этих случаях всё равно будет какой-то маршалинг результата/ошибок.

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

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

Ну, так почему такого не сделали в Go, а вместо этого if'ы проверки ошибок?

Сообщение отредактировано: MyNameIsIgor - 15.05.15, 15:12

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

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

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

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

Цитата DarkEld3r @ 15.05.15, 13:57

Ну так там они и описывают когда можно, а когда нет.

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

Добавлено 15.05.15, 14:40

Цитата DarkEld3r @ 15.05.15, 13:57

Хотя раньше (подозреваю, что и сейчас, но проверять лень) они подстилали соломку: ловили такие исключения и писали в лог о неправильном использовании.

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

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

Наружу чего? Все корутины равноценны, нет никакой «наружи».

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

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

1) И что? Всегда есть некая сущность их вызывающая. В асинхронных I/O системах это может быть планировщик этих самых корутин.

2) Почему обязательно main? Если корутина сама не обработала исключение, значит можно считать что она просто подохла.

3) Допустим во фреймворке vibe.d в случае подобного поведения файбера если ошибка дойдет до планировщика, то он просто выведет в лог сообщение, что такая-то корутина померла с такой-то ошибкой. На более высоких уровнях можно обрабатывать эти ошибки. Допустим http-сервер в случае издыхания корутины-обработчика запроса, выдает 503 ошибку.

4) Я очень плотно работаю с конкурентной асинхронной системой построенной на файберах и нахожу исключения архиполезными.

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

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

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

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

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

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

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

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