System.exit (0) в Java
function get_col_names(){
$sql = "SHOW COLUMNS FROM tableName";
$result = mysql_query($sql);
while($record = mysql_fetch_array($result)){
$fields[] = $record['0'];
}
foreach ($fields as $value){
echo 'column name is : '.$value.'-';
}
}
return get_col_names();
5 ответов
Лично я считаю наилучшей практикой позволить приложению завершиться само по себе: если вы напишете основной класс с main (String [] args) , с пустым кодом, его выполнение автоматически завершится из Программа на Java.
Но в большинстве случаев, как и большинство разработчиков, я полагаюсь на System.exit (/ код выхода /) , особенно для приложений Swing, где Swing EDT будет работать бесконечно, как писал justkt . Известный недостаток этого метода заключается в том, что большая часть кода приложения не вызывается, чего я избегаю, устанавливая ловушку выключения, вызывая Runtime.addShutdownHook (Thread) , что позволит мне очистить приложение (закрыть потоки и т. Д.).
System.exit может быть плохим, по крайней мере, если у вас есть несколько потоков или ресурсов, которые необходимо закрыть должным образом (которые находятся вне JVM). Если ваше приложение не закрывается, когда вы думаете, что это должно быть, вы должны выяснить, в чем проблема, а не просто вызвать System.exit ().
Единственная причина для вызова System.exit () - дать какой-то нестандартный код выхода.
Если вам нужно установить код выхода для вашего приложения, вы должны использовать System.exit (я думаю).
Но когда вам не нужен конкретный код (или 0 в порядке), я бы предпочел, чтобы JVM завершалась «естественным образом», что происходит, когда больше не осталось (не-демонов) потоков.
Обычно вы просто доходите до конца своего основного метода.
Я был бы осторожен с System.exit, потому что могут быть другие потоки, которым все еще нужно что-то делать, и выход без их правильного завершения может привести к повреждению. Например, встроенной базе данных может потребоваться очистка буферов.
Если вы знаете об этих цепочках, вы обычно можете организовать их изящное завершение. Если вы не знаете, какие потоки выполняются в вашей программе, у вас большие проблемы ...
Вообще говоря, единственный раз, когда вам нужно выполнить System.exit (n), это если вы хотите выйти из программы командной строки с кодом ошибки, чтобы все, что контролирует программу, могло обнаружить код ошибки.
Это наиболее полезно, например, если вы пишете программу, предназначенную для запуска из сценария оболочки.
Однако, как говорится в других ответах, если вы используете потоки, вы должны приложить все усилия, чтобы корректно их завершить, прежде чем рассматривать System.exit (n)
В общем, вызов System.exit (...) где угодно, кроме «основного» метода приложения, может быть проблематичным (по крайней мере) для следующих причины.
Это препятствие для повторного использования вашего кода.
Это затрудняет модульное тестирование. Например, если ваш код вызывает
System.exit, когда ваши тесты JUnit осуществляют некоторую обработку ошибок, это конец вашей тестовой последовательности!
Конкретный случай вызова System.exit (...) в прослушивателе кнопки для кнопки «выход» не так уж и плох. Маловероятно, что вы захотите повторно использовать прослушиватель кнопок где-нибудь, где также не требуется такое поведение. Кроме того, вы, вероятно, сможете найти способ решения головоломки модульного тестирования; например не тестируйте этот конкретный метод!
Тем не менее, я думаю, что все же я бы попытался добиться выхода другим способом. Например, пусть метод main запускает все, а затем блокируется на CountDownLatch, а затем слушатель кнопки уменьшает защелку. Когда метод main разблокируется, он выполняет соответствующий код выключения и возвращает или завершает работу в зависимости от ситуации.