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

Цитата amk @ 15.05.15, 06:01

Ты ведь никогда не слышал, чтобы на каждого космонавта в космос брали по 12 скафандров?

Абсолютно не в курсе по сколько там берут

Добавлено 15.05.15, 07:16
Хотя интересно Эта инфа о 12-кратной страховке запомнилась уже и не знаю когда. Щя задался вопросом, откуда эти ноги растут

Добавлено 15.05.15, 07:24
Погуглил, пока нашел в различных местах инфу о требовании 12-кратного запаса по прочности (истребители, канаты, альпинистское снаряжение ...), по току (регуляторы мощности) Про дублирование функций управляющих систем не нашел. Мистика.

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

Цитата https://golang.org/doc/faq#exceptions

We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. It also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional.

Go takes a different approach. For plain error handling, Go's multi-value returns make it easy to report an error without overloading the return value. A canonical error type, coupled with Go's other features, makes error handling pleasant but quite different from that in other languages.

Go also has a couple of built-in functions to signal and recover from truly exceptional conditions. The recovery mechanism is executed only as part of a function's state being torn down after an error, which is sufficient to handle catastrophe but requires no extra control structures and, when used well, can result in clean error-handling code.

"Поощряет программистов считать многие обычные ошибки, таких как ошибка открытия файла, исключительными.". Такое впечатление, что в Google ошибки открытия файла - это штатная ситуация.

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

Цитата JoeUser @ 14.05.15, 20:00

Время идет, соединения нет. Как обработать исключительную ситуацию??? Обработать эксепшен в стиле "Сохранить решение для следующего обвиняемого???" Разницы нет - ассерт - эксепшен !!!

Отловили ексепшн — нормально (при)остановили гильотину. Выбросился ассерт — ПО потеряло контроль над железом, гильотина пустилась в свободное плавание, КРОВЬ-КИШКИ-РАСПberry Pi.

Добавлено 15.05.15, 09:11

Цитата applegame @ 15.05.15, 08:13

"Поощряет программистов считать многие обычные ошибки, таких как ошибка открытия файла, исключительными.". Такое впечатление, что в Google ошибки открытия файла - это штатная ситуация.

Ошибка открытия файла — вполне себе обыденная ситуация. Не помню где, читал так же мнение, что с исключениями как-то не всё однозначно в конкуррентном коде.

Цитата korvin @ 15.05.15, 09:09

Ошибка открытия файла — вполне себе обыденная ситуация.

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

Цитата korvin @ 15.05.15, 09:09

Не помню где, читал так же мнение, что с исключениями как-то не всё однозначно в конкуррентном коде.

Интересно, что именно с ними не так однознчно? У них вроде только один недостаток - некоторый оверхед, который в некоторых случаях может быть нежелателен.

Цитата korvin @ 15.05.15, 09:09

ПО потеряло контроль над железом, гильотина пустилась в свободное плавание,

Там ващета говорилось о программах на планшетах

M

Итак, тематического разговора не получилось. Причём, стараниями самого ТС. Передо мной выбор: банка за флуд и неподчинение модератору или снос темы во флейм. Вы знаете моё отношение к банкам, так что не удивлю, если скажу, что сам я склоняюсь ко второму варианту. Но там тема зарастёт флудом куда сильнее.
Итак, каков ваш выбор? Жду до вечера.

Добавлено 15.05.15, 10:18

Цитата JoeUser @ 14.05.15, 22:28

По поводу "отказоустойчивости".

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

Добавлено 15.05.15, 10:27

Цитата applegame @ 15.05.15, 08:13

Аргументация разработчиков Go какая-то никудышная:

Никудышняя. Забей, стопудоф они просто не осилили, и сделали хорошую мину.
Что считать исключительной ситуацией, а что нет – это сугубо личное дело архитектора системы. По определению ситуация исключительна, если не позволяет далее исполнять контракт. Деление на нуль. Возврат ссылки в никуда. Не предусмотренная архитектурой ПО ситуация (привет ассертам). Вот тупо невозможно и всё тут, следующая инструкция не может быть исполнена процессором, так что единственный выход – передача управления куда-то назад, где работать ещё было можно. Если ситуация предусмотрена архитектурой, она априори не исключительна, а предусмотрена бизнес-логикой.

Цитата applegame @ 15.05.15, 08:13

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

Самое забавное, что в Go вполне можно использовать их "панику" как исключения:

func trowException() {
    fmt.Println("Throwing 'exception'")
    panic("'exception'")
}
 
func main() {
    defer func() {
            if r := recover(); r != nil {
            fmt.Println("Catching ", r)
            }
        }()
    trowException()
}

Так что "отказ", по моему, выглядит просто как "мы сделаем исключения неудобными и не будем поощрять их в АПИ".
Опять же, постулируется, что "традиционные исключения" неудобные и неявно нарушают поток выполнения, но по моему гошное решение ничем не лучше. А по читаемости так ещё и хуже, более очевидных, try/catch блоков. Может, конечно, я чего-то не понимаю.


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

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

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

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

А так же режим доступа и, возможно, что-то ещё. Вот это и делается, в результате выдаётся дескриптор и значение типа error, которое в случае успешной операции является просто nil, иначе содержит информацию о причинах неудачи. Всяко лучше, чем тупой false.

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

Цитата DarkEld3r @ 15.05.15, 11:29

Самое забавное, что в Go вполне можно использовать их "панику" как исключения:

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

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

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

Интересно, что именно с ними не так однознчно? У них вроде только один недостаток - некоторый оверхед, который в некоторых случаях может быть нежелателен.

Сходу найти не смог, но вот на тему: http://www.lighterra.com/papers/exceptionsharmful/

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

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

А так же режим доступа и, возможно, что-то ещё. Вот это и делается, в результате выдаётся дескриптор и значение типа error, которое в случае успешной операции является просто nil, иначе содержит информацию о причинах неудачи. Всяко лучше, чем тупой false.

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

Цитата Qraizer @ 15.05.15, 10:15

По определению ситуация исключительна, если не позволяет далее исполнять контракт

Если мы соблюдаем контракт без файла, то ничего исключительного нет. Потому и делать следует как-то так

template<typename SyncReadStream, typename MutableBufferSequence>
std::size_t read(SyncReadStream & s, const MutableBufferSequence & buffers);
 
template<typename SyncReadStream, typename MutableBufferSequence>
std::size_t read(SyncReadStream & s, const MutableBufferSequence & buffers, boost::system::error_code & ec);

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

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

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

Ну дык, я об этом и написал. Но это ведь никак не тянет на "отказ от исключений" (на уровне языка). Вон в С++ в стандартной библиотеке практически нет исключений. В Qt вообще нет. Но пользоваться ими не мешают.

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

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

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

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

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

Зависит. Но какой смысл тогда собственно в исключениях? Если мы их перехватываем, то это равнозначно проверке кода ошибки. Да, исключения позволяют избавиться от вереницы if'ов, например, но в том же Хаскелле с этим не менее успешно справляются монады. Если же мы их не перехватываем, то чем они отличаются от abort() или там System.exit(EXIT_CODE)?

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

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

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

Отдельные случаи? Конкуррентного кода становится всё больше и больше. Не понимаю, почему бы ради такого удобного механизма не пожертвовать какими-то исключениями? =)

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

Если мы их перехватываем, то это равнозначно проверке кода ошибки.

Перехватывать мы их можем где угодно выше по стеку. Получаем такие профиты, как 1) отсутствие необходимости руками заботливо передавать ошибку и 2) полиморфные объекты ошибок позволяют передавать различную информацию об ошибке, не изменяя API.

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

Да, исключения позволяют избавиться от вереницы if'ов, например, но в том же Хаскелле с этим не менее успешно справляются монады.

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

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

Ну дык, я об этом и написал. Но это ведь никак не тянет на "отказ от исключений" (на уровне языка). Вон в С++ в стандартной библиотеке практически нет исключений. В Qt вообще нет. Но пользоваться ими не мешают.

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

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

Не понимаю, почему бы ради такого удобного механизма не пожертвовать какими-то исключениями? =)

Погоди. А почему ради конкурентного кода необходимо жертвовать исключениями? Из-за этого?

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

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

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

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

но в том же Хаскелле с этим не менее успешно справляются монады

Вроде, в хаскеле тоже можно пробрасывать ошибки через несколько уровней и ловить их потом (error/catch) без оборачивания результата промежуточных функций в монады?

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

не менее успешно справляются монады

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

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

Конкуррентного кода становится всё больше и больше. Не понимаю, почему бы ради такого удобного механизма не пожертвовать какими-то исключениями? =)

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