Почему я не должен использовать Process.GetCurrentProcess (). Kill () для выхода из приложения WinForm?

Question

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

• Выход из всех моих основных циклов с использованием логических значений
• прервать все еще работающие потоки (как правило, мой поток опроса сервера)
• любезно позвоните Application.Exit ();

Это займет несколько секунд, чтобы выйти, и не служит никакой реальной цели (все уже сохранено на сервере, поэтому мне все равно, что там происходит)

Если я использую это вместо этого, я получу мгновенное завершение без недостатка, о котором я могу думать:

 System.Diagnostics.Process.GetCurrentProcess().Kill();

Почему бы мне просто не завершить процесс и не дать CLR удалить домен приложений?

Я знаю, что тщательная утилизация ваших общих ресурсов (обработчики файлов IO и т. Д.) Важна (поэтому, пожалуйста, не отвечайте :)), но как только это будет сделано, есть ли реальная причина для чистого выхода из моего приложения? 1018 *

Answer 1

Завершение процесса будет означать, что в конечном итоге блоки не будут выполнены, и, вероятно, даже критических объектов финализатора , которые на самом деле могут быть критическими, и вызвать утечку ресурсов на системном уровне. Это может также привести к неожиданным ошибкам в будущем, когда кто-то другой будет поддерживать код, поскольку им (или вам) придется крутить головой, каждый раз думая, когда они пишут блок finally, будет ли он выполняться.

Answer 2

Это действительно хороший вопрос!

Однажды (более десяти лет назад) я написал приложение VB6, которое зависало при завершении работы из-за подтвержденной ошибки в WinINet OCX (или как она там была вызвана) из-за конкретного сертификата, используемого на веб-сервере, на котором оно было разговаривать с

Без какого-либо способа обойти эту ошибку я использовал TerminateProcess, и, насколько мне известно, это приложение использовалось на нескольких тысячах компьютеров в течение нескольких лет, и я никогда не слышал о каких-либо проблемах с этим взломом!

Answer 3

Во-первых, я думаю, что вы имеете в виду Process.Kill(), а не Process.TerminateProcess(). Во-вторых, убийство процесса просто порвет его. Любой код очистки не будет выполнен, и ваше приложение не получит возможность отменить удаление (например, если у пользователя есть несохраненные данные). Если ты доволен этим, иди на это.

Answer 4

Использование сторонних библиотек без возможности отловить их ошибки или утечки, иногда единственный способ завершить его, не вызывая аварийный сбой MessageBox, - это завершить процесс.

Answer 5

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

В общем, я бы не стал сильно беспокоиться о том, что закрытие приложения займет несколько секунд, особенно если оно сразу скрывает все свои окна и «исчезает» для пользователя. Однако, если закрытие занимает десятки секунд и / или пользователь, вероятно, снова выполнит приложение и оно не поддерживает несколько экземпляров, вызов Process.Kill может быть хорошей идеей.

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

Answer 6

Имейте в виду, что если вы пишете в файл / сетевой поток, возможно, ваша запись будет неполной.

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

Answer 7

Почему бы не использовать System.Environment.Exit (int) ? Похоже, вы хотите сделать это просто для сохранения кода. Для меня гораздо яснее увидеть, как работает Exit, и ваше отключение будет более управляемым, будут работать финализаторы и критические финализаторы.