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

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

Закройте все мои mainloops с помощью booleans
прервать выполняемые потоки (как правило, поток опроса сервера)
добрый вызов Application.Exit();

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

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

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

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

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

Ответ 1

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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