Подтвердить что ты не робот

Альтернативы System.exit(1)

По различным причинам вызов System.exit неодобрился при написании Java-приложений, поэтому как я могу уведомить вызывающий процесс, что не все идет по плану?

Изменить: 1 - это standin для любого ненулевого кода выхода.

4b9b3361

Ответ 1

Использование System.exit неодобрительно, когда "приложение" действительно является под-приложением (например, сервлет, апплет) более крупного приложения Java (сервер): в этом случае System.exit может остановить JVM и следовательно, все другие под-приложения. В этой ситуации наилучшим вариантом может быть выбрасывание соответствующего исключения, которое может быть захвачено и обработано инфраструктурой/сервером приложения.

Если приложение java действительно предназначено для запуска как автономное приложение, нет ничего плохого в использовании System.exit. в этом случае установка значения выхода, вероятно, является самым простым (а также наиболее часто используемым) способом передачи отказа или успеха родительскому процессу.

Ответ 2

Я согласен с толпой "бросить исключение". Одна из причин заключается в том, что вызов System.exit затрудняет использование вашего кода, если вы хотите, чтобы другой код мог его использовать. Например, если вы узнаете, что ваш класс будет полезен из веб-приложения или какого-то приложения, потребляющего сообщения, было бы неплохо разрешить этим контейнерам возможность как-то справиться с отказом. Контейнер может захотеть повторить операцию, принять решение о регистрации и игнорировать проблему, отправить электронное письмо администратору и т.д.

Исключением для этого будет ваш метод main(); это может заблокировать исключение и вызвать System.exit() с некоторым значением, которое может быть распознано вызывающим процессом или оболочкой script.

Ответ 3

System.exit() будет блокировать и создавать тупик, если инициированный поток используется в завершении работы.

Ответ 4

Наша политика компании заключается в том, что ОК (даже предпочтительнее) вызывать System.exit(-1), но только в методах init(). Я бы определенно подумал дважды, прежде чем называть его во время обычного потока программы.

Ответ 5

Он нахмурился за обычные выходы. Если "не все идет по плану", то System.exit в порядке.

Обновление: я должен добавить, что я предполагаю, что ваш "1" имеет значение, которое где-то документировано.

Ответ 6

Это может быть опасно и проблематично в средах веб-сервлета.

Бросьте исключение, как правило, считается другой альтернативой.

Ответ 7

Броски исключений - лучший способ отправить информацию об определенной ошибке и из приложения.

Число не говорит вам столько, сколько:

Exception at thread 'main': FileNotFoundException "The file 'foo' doesn't exist"

(или что-то близкое к этому)

Ответ 8

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

Важно отметить, что когда исключение достигает верхнего уровня и поэтому приводит к тому, что виртуальная машина завершает работу, VM возвращает код возврата из 1, поэтому внешние приложения, использующие код возврата, видят, что что-то пошло не так.

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