Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Исключения в C++ (3 стр)

Исключения в C++ (3 стр)

Страницы: 1 2 3 4 58 Следующая »
ashujonПостоялецwww15 мая 201813:48#30
Ghost2
> И что должна делать программа после того, как конструктор объекта, который в ее
> контексте должен быть валидным, бросил исключение?
программа передает исключение выше после того как корректно очищает все объекты что успела создать, т.к. программист не дурак и использует RAII
Ghost2Постоялецwww15 мая 201814:27#31
ashujon

> программа передает исключение выше после того как корректно очищает все объекты что успела создать
А там где-то стоит catch(...), ну или catch(my_base_exception), который валит все вместе и зовет exit().
Может лучше тогда создавать дефолтные объекты и не кидаться чем попало в main?

DelfigamerПостоялецwww15 мая 201814:29#32
Ghost2
> А там где-то стоит catch(...), ну или catch(my_base_exception), который валит
> все вместе и зовет exit().
> Может лучше тогда создавать дефолтные объекты и не кидаться чем попало в main?
Ну конечно, если ты не пользуешься исключениями, они тебе и не нужны.
Основная логика исключений в том, что программист обрабатывает ошибка там, где с ними можно справиться.
Вот пишешь ты буфер в поток, а тут внезапно место на диске кончилось и fwrite взял и послал твой serialize<FILE*, int>() гулять на свежем воздухе. И что он сделает? Ничего он не может сделать, поэтому он разводит руки и поднимает исключение. Зато выше по стеку у какого-нибудь savegamestate() средства для этого есть - он ловит исключение и выводит игроку окошко с текстом "не получилось сохранить игру потому что вот". Остальному коду на сохранёнки наплевать, поэтому игра продолжает работать без всякий падений и exit().
Аналогичная ситуация, если возникнет ошибка при передаче буфера по TCP-туннелю. Тот же serialize<tcptunnel, int>() ничего на месте не сделает, а вот верхние уровни подсистемы репликации смогут потерянного клиента дропнуть, и серверу больше не нужно падать.
А вот если в этих случаях тупо игнорировать ошибку и делать вид, будто всё хорошо и передавать дефолты; то получатся навечно зависшие клиенты и рваные сейвы. Разумеется, при попытке загрузить рваный сейв, твой игровой мир окажется в совершенно непредсказуемом состоянии - лучше ж дефолтные нули проставить, пусть игрок завершает свой квест как хочет.

Правка: 15 мая 2018 14:45

Ghost2Постоялецwww15 мая 201814:56#33
Delfigamer

> что программист обрабатывает ошибка там, где с ними можно справиться
У С++ в этом моменте есть определенные проблемы.

> Вот пишешь ты буфер в поток, а тут внезапно место на диске кончилось
С вводом/выводом очень прикольный пример, потому что стандартные iostream исключений по умолчанию никуда не кидают.

> И что он сделает? Ничего он не может сделать
Запишет лог и вернет false.

> он ловит исключение и выводит игроку окошко с текстом "не получилось сохранить игру потому что вот"
А там где-то будет показано точно такое-же окошко, только с надписью "не получилось сохранить игру, смотри лог".

Правка: 15 мая 2018 15:02

innuendoПостоялецwww15 мая 201815:06#34
Ghost2

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

HardMorgПостоялецwww15 мая 201815:43#35
Ghost2
Вам уже ответили, обрабатывать там, где есть знания об ошибке. Встречный вопрос, как проектировать классы, а точнее конструкторы в которых может возникнуть ошибка но конструктор не должен кидать исключение?
ashujonПостоялецwww15 мая 201815:49#36
HardMorg
> но конструктор не должен кидать исключение
этому есть какая-то причина?
DelfigamerПостоялецwww15 мая 201816:10#37
ashujon
> этому есть какая-то причина?
Невозможно открыть файл.

Ghost2
> вернет false
Возврат кодов ошибок через стек - это те же самые исключения, только велосипедные и без автоматизации со стороны компилятора.

Ghost2
> У С++ в этом моменте есть определенные проблемы.
По сравнению с чем и какие именно?

Правка: 15 мая 2018 16:11

ashujonПостоялецwww15 мая 201816:32#38
Delfigamer
> Невозможно открыть файл.
что мешает кинуть исключение в этом случае?
Ghost2Постоялецwww15 мая 201816:42#39
innuendo

> при обработки сигналов с радара можно не юзать исключения
Радиолокатор, помимо обработки сигналов, делает еще кучу вещей. Обработка сигналов - это где-то процентов 5 всего кода.
И до недавнего времени она у нас выполнялась на отдельном процессоре. С таким количеством памяти, что ему не до исключений.

HardMorg

> Встречный вопрос, как проектировать классы, а точнее конструкторы в которых
> может возникнуть ошибка но конструктор не должен кидать исключение?
Использовать дефолтные объекты (как некое продолжение варианта google), dependency injection.

ashujon

> этому есть какая-то причина?
Есть конечно - их ловить надо. И если ты не поймал нужный тип исключения сейчас, то уж наверху его точно никто не поймает. А если и поймает, то не будет знать, что с ним делать.
Исключения это хорошо для кейсов типа "сделай мне это, если отвалится я хочу вернуть управление сюда". Без всякого recovery.
Тут я согласен, гемора немножко меньше, сам юзаю иногда.

Delfigamer

> По сравнению с чем и какие именно?
В плюсах же нет checked исключений.

Ghost2Постоялецwww15 мая 201816:45#40
Delfigamer

> только велосипедные и без автоматизации со стороны компилятора.
Была бы там автоматизация и проверки, никто бы и не спорил.
А так throw - это просто goto неизвестно куда.

DelfigamerПостоялецwww15 мая 201817:43#41
ashujon
> что мешает кинуть исключение в этом случае?
Я думал, ты спрашивал примеры причин, чтобы кидать. :/

Ghost2
> В плюсах же нет checked исключений.
Это где ты рядом с методом руками перечисляешь каждую деталь, которая может пойти не так? С добрым утром, была у них такая фаза, и потом прошла, потому что от них только геморрой. Вместо них сделали один флаг, который сообщает действительно важную информацию - бросает ли функция исключения или нет.

Ghost2
> А так throw - это просто goto неизвестно куда.
throw - это "запрошенная операция не может быть осуществлена".
Как правило, если функция А вызывает функцию Б, то для успешного выполнения задачи, которая стоит перед А, абсолютно необходимо, чтобы свою собственную задачу выполнила Б. Соответственно, если выполнить Б по какой-то причине невозможно - то и операция А так же должна закончиться неудачей.
Если же у нас один из редких случаев, когда можно успешно сделать А, даже когда Б невозможно - заворачиваем Б в try, и действия в случае неудачи Б описываем в блоках catch.
Ничего сверхъестественного в духе "return [](){}" и локфри-алгоритмов в этой логике нет.

Ghost2
> Есть конечно - их ловить надо. И если ты не поймал нужный тип исключения
> сейчас, то уж наверху его точно никто не поймает. А если и поймает, то не будет
> знать, что с ним делать.
А типа твои return false проверять не надо?

Правка: 15 мая 2018 17:44

Ghost2Постоялецwww15 мая 201818:35#42
Delfigamer

> С добрым утром, была у них такая фаза
Ты думаешь, что я не в курсе? Оно в принципе нигде не работало и ничего не гарантировало.
Потому и стало deprecated.

> и потом прошла, потому что от них только геморрой
Потому что от них в С++ геморрой. В Java вот используют.

> Как правило, если функция А вызывает функцию Б...
Не надо мне зачитывать отрывки из букваря. Я если ввязался в это обсуждение, то уж как-нибудь представляю, зачем они нужны и как работают.

> который сообщает действительно важную информацию - бросает ли функция исключения или нет.
И к чему это обязывает?

> А типа твои return false проверять не надо?
Дело не в том, надо или не надо, а в том, что конкретно проверять/ловить.
С true/false хотя-бы ясно, где будет программа после вызова.

ashujonПостоялецwww15 мая 201818:58#43
Ghost2
> И к чему это обязывает?
это обязывает программиста следить чтобы функция на самом деле не бросала исключения, т.к. если это происходит то программа завершается без передачи исключения выше
и это упрощает жизнь тем кто пользуется чужим кодом, т.к. они понимают что исключение точно не бросится на этой функции, а если и бросится то они все равно ничего не смогут сделать
и это позволяет компилятору генерировать меньше кода

Правка: 15 мая 2018 19:04

MrShoorУчастникwww15 мая 201819:04#44
ashujon
> это обязывает программиста следить чтобы функция на самом деле не бросала
> исключения
Нет, не для этого noexcept придумали.
Страницы: 1 2 3 4 58 Следующая »

/ Форум / Программирование игр / Общее

2001—2018 © GameDev.ru — Разработка игр