Почему использование exit() считается плохой?

Я читаю этот вопрос, и есть ответ, объясняющий, почему использование exit() плохо, потому что:

  • В результате у вас будет несколько точек выхода из программы
  • Он делает код более запутанным (например, с помощью goto)
  • Он не может освободить память, выделенную во время выполнения

Я должен уточнить, что я использую Qt, поэтому код уже немного "запутан", так как я использую сигналы и слоты. При этом, для вопроса № 1, я вижу, что это связано с №2, но мой код в настоящее время пытается избежать использования exit(), потому что мне сказали, что это сделает мой код похожим на беспорядок, но избегать exit сделал это беспорядок. У меня есть функции, которые не должны ничего возвращать, возвращая вещи. Например, когда у меня есть регистрация пользователей, и их имя пользователя уже существует, вместо того, чтобы просто вызвать exit() после того, как пользователь не выполнил регистрацию пользователя (что является желательным поведением в этой ситуации), я возвращаю false к функции, которая возвращает false к другой функции, которая затем возвращает false в мою основную часть, которая затем проверяет, вернулась ли эта функция true или false, и если она возвращает false, то она возвращает 0. Так много, чтобы избежать exit() сделать код чистым.

Для третьей проблемы, не используя exit(0), сообщите ОС, что программа выполнена, и ОС освободит эту память в любом случае? Я запускал тестовый пример, который использует exit(0), когда я нажимаю кнопку, и процесс удаляется из списка процессов, и память освобождается, так почему же это даже проблема? Кажется, это откровенное ложное утверждение, по крайней мере, в Windows.

Ответ 1

Просто слепой вызов exit() где-то в вашей программе считается плохим по простой причине:

Он не закрывает должным образом другие потоки (они просто прекращаются), он не очищает должным образом все буферы (очищаются файлы stdio) и гарантирует согласованное и действительное состояние постоянных/общих ресурсов (файлов/общей памяти/других способов связи).

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

Многие современные программы запрограммированы для еще более быстрого выключения:

Он устойчив к сбоям, почти каждый раз просто выключается, например, с помощью _Exit() (даже не вызывая atexit или at_quick_exit зарегистрированных хуков) в порядке. В большинстве случаев это намного быстрее, чем упорядоченное завершение работы (если возможно, ресурсы пользовательского интерфейса Windows следует сначала уничтожить, поскольку они являются исключением).

Для дальнейшего чтения: Crash-only software (PDF!)

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

Ответ 2

Пункты 1 и 2, я не согласен. Это больше вопросов стиля и предпочтений.

Что касается пункта 3, вы должны посмотреть документацию, чтобы увидеть, что она на самом деле будет или не будет бесплатной или флешей (http://en.cppreference.com/w/cpp/utility/program/exit и http://msdn.microsoft.com/en-us/library/6wdz5232.aspx). Например, в документации MS говорится: "Сбрасывает все буферы файлов до того, как он завершит процесс".

Когда ваша программа выйдет, ОС вернет память, но это не то, о чем он говорит. Он имеет в виду, что такие ресурсы, как семафоры, не будут выпущены должным образом или своевременно. Может быть, это проблема, возможно, нет, в зависимости от того, какие ресурсы вы используете.