Комментарии 18
а для Java подобное тестирование планируется?
а что-нибудь более реальное — типа исключение — это действительно в исключительной ситуации, объектов десяток нетривиальных создать/разрушить, ошибка в функции 3-4 уровней вложенности, а реакция выше. ну где-то так?
а потом сравнить быстродействие и объем кода, бойлер-плейта и мест для ошибки для разных вариантов.
а, пардон, это перевод. ну не самая удачная статья для перевода выбрана кмк
У вас реально может быть 50% ошибок, например, при парсинге данных снаружи. Конечно, когда процент ошибок становится выше определенного порога, то начинают костылить в стиле bool TryDoStuff
, где через аут параметры возвращаются реальные данные, а булкой показывают, удачно ли прошла операция и можно ли пользоваться возвращаемым значением.
Только вот во-первых аут параметры это очень фигово (композятся они так себе, это точно), а во-вторых можно легко использовать мусорное значение, не проверив успешность операции.
С подобным expected вероятность подобного исхода ниже, а с полноценными АДТ — нулевая.
Они на то и исключения, чтобы не возникать часто — насколько оправдано вообще с этим заморачиваться в плане штатной работы приложения?
я за подход без исключений, но с простым прокидыванием ошибки наверх, например в расте нужно просто дописать знак вопроса после операции которая может завершиться ошибкой. В итоге имеем лучшее из обоих миров.
Автор оригинала не прав совсем. Скорость зависит от процентного соотношения ошибок и правильного кода, и при малом проценте ошибок исключения быстрее.
Теперь придется вам перевести еще и это https://nibblestew.blogspot.com/2017/01/measuring-execution-performance-of-c.html. Тут более подробнее правда уже на старых компиляторах.
Судя по всему, предложенное решение сочетает в себе минусы и от retval в стиле Си, и от плюсовых исключений: и (сравнительно) медленное, и может легко быть проигнорировано. Опять же, если исключение должно лететь уровней на пять вверх, весь код там превратится в лапшу из if'ов и переупаковывания Expected'ов.
В конце концов все изобретают очередной вариант на тему Either.
Статья демонстрирует, что если исключения не ловить, а возвращать как коды ошибок — то они сравнимы со скоростью кодов ошибок. Не очень полезное знание. И конечно потеря RAII, разматывания стека и всех тех преимуществ исключений, которые в статье обозначены.
Автор оригинала совсем не прав, ибо сравнил теплое с мягким и сделал вывод что одно кислее другого. Еще и Александреску приплел.
- Скорость вброса-обработки исключений не влияет на производительность, так как в нормальном коде исключения очень редки.
- Рецепт Александреску не про производительность, а для возврата и обработки ошибок в Go-стиле, что во многих случаях проще-удобнее по ряду причин.
- Предлагаемый "возврат исключений" быстрее только в случае возврата псевдо-исключений с тривиальной структурой (код ошибки), что и демонстрируют результаты (замедление в ~5 раз для normal-path).
Если не округлять углы, то в статье примерно пурга, которая только путает "джунов".
Не надо забывать, что исключения совсем не zero cost даже, когда не бросаются, иначе бы noexcept в стандарт не тащили. Кроме затрат непосредственно на секцию try, которая в реализации SJLJ может быть очень недешёвой, есть ещё и косвенные на сломанные оптимизации. Сейчас с ходу не найду доклад, но точно был про внутренности llvm, где демонстрировалось, какие именно оптимизации ломаются.
Кроме того есть ещё разбухание бинаря (привет dwarf), -fno-exceptions и прочие интересные случаи.
Как сократить накладные расходы при обработке исключений в С++