JC
Ну так не optional единым
Size: a a a
2020 September 27
JC
Есть же std::variant
AB
Но есть же ексепшен!
JC
ну, да, а он нужен?
JC
Эксепшены ж по перформансу сильно бьют, нет?
AB
Ладно, я залезаю в спор, не люблю это
AB
Эксепшены ж по перформансу сильно бьют, нет?
Да, но удобнее
V
Узнать что выходные данные получены задача тривиальная, сложнее когда надо писать обработчики поведений
Чем вызов throw лучше return? (если сам пишешь процедуру, а не использую готовую, где уже ничего не сделать)
AB
Эксепшены ж по перформансу сильно бьют, нет?
Не все секции кода под нагрузкой, где-то резонно ошибки отлавливать чем-то более скоростным
V
Ладно, я залезаю в спор, не люблю это
Всё же огромная слабость плюсов в их разнообразии (как у линукса с дистрибутивами), нет какого-то одного стабильного бест практикс во многих вопросах (в идеале — единственный или обезоруживающе лучший способ), в каждом проекте что-то своё
JC
Да, но удобнее
А чем?
JC
Я для себя вижу мб то, что сначала пишется код как есть, а потом просто catch исключительных ситуаций.
Вместо ифов которые будут прорежать код.
Вместо ифов которые будут прорежать код.
V
Вот я использую Qt и его кору в частности активнее, чем stl, и могу не бояться говорить плохо об исключениях
А кто-то иной stl only, и внутри почти используемых либ получает исключения
И всё, приходится терпеть
А кто-то иной stl only, и внутри почти используемых либ получает исключения
И всё, приходится терпеть
JC
Но еррор-вариант меня подкупает явностью и тем, что обработка ошибок выносится на уровень системы типов
AB
Чем вызов throw лучше return? (если сам пишешь процедуру, а не использую готовую, где уже ничего не сделать)
В плане лучше? Ретурном ты можешь вернуть либо полезные данные, в которых зарезервировать часть диапазона значений под ошибки, либо просто возвращать код ошибки, а данные через указатели в параметрах
Ексепшен же явно специфицирует что он не связан с полезными данными и к ретурну отношения не имеет, только к ловящему блоку трай-кэтч
Ексепшен же явно специфицирует что он не связан с полезными данными и к ретурну отношения не имеет, только к ловящему блоку трай-кэтч
AB
Я для себя вижу мб то, что сначала пишется код как есть, а потом просто catch исключительных ситуаций.
Вместо ифов которые будут прорежать код.
Вместо ифов которые будут прорежать код.
Да, именно в этом
Был на проекте где ребята своим механизмом исключений пользовались, ещё написанным в бородатых 90х. Там всё было слегка по своему, а сейчас уже поддерживается нативно языком
Был на проекте где ребята своим механизмом исключений пользовались, ещё написанным в бородатых 90х. Там всё было слегка по своему, а сейчас уже поддерживается нативно языком
V
В плане лучше? Ретурном ты можешь вернуть либо полезные данные, в которых зарезервировать часть диапазона значений под ошибки, либо просто возвращать код ошибки, а данные через указатели в параметрах
Ексепшен же явно специфицирует что он не связан с полезными данными и к ретурну отношения не имеет, только к ловящему блоку трай-кэтч
Ексепшен же явно специфицирует что он не связан с полезными данными и к ретурну отношения не имеет, только к ловящему блоку трай-кэтч
Ну вот способ, как вариант
Чем это принципиально хуже вызова исключения?
Да, возможно может быть чуть многословнее, но в целом довольно прямолинейно
Чем это принципиально хуже вызова исключения?
Да, возможно может быть чуть многословнее, но в целом довольно прямолинейно
AB
Да, именно в этом
Был на проекте где ребята своим механизмом исключений пользовались, ещё написанным в бородатых 90х. Там всё было слегка по своему, а сейчас уже поддерживается нативно языком
Был на проекте где ребята своим механизмом исключений пользовались, ещё написанным в бородатых 90х. Там всё было слегка по своему, а сейчас уже поддерживается нативно языком
.
AB
Тоже самое, но в профиль
AB
Если удобно, то велком