java System.exit(1) 的替代方案

Alternatives to System.exit(1)

提问by Allain Lalonde

For various reasons calling System.exitis frowned upon when writing Java Applications, so how can I notify the calling process that not everything is going according to plan?

由于各种原因System.exit，在编写Java Applications时调用是不受欢迎的，那么我如何通知调用过程并非一切都按计划进行？

Edit:The 1 is a standinfor any non-zero exit code.

编辑：1 是standin任何非零退出代码的 a 。

回答by Gio

The use of System.exitis frowned upon when the 'application' is really a sub-application (e.g. servlet, applet) of a larger Java application (server): in this case the System.exitcould stop the JVM and hence also all other sub-applications. In this situation, throwing an appropriate exception, which could be caught and handled by the application framework/server is the best option.

采用System.exit较大的Java应用程序（服务器）的时候，“应用程序”是一个真正的子应用是不可取的（如小服务程序，小应用程序）：在这种情况下，System.exit可能停止JVM，因此也是所有其他的子应用程序。在这种情况下，抛出一个可以被应用程序框架/服务器捕获和处理的适当异常是最好的选择。

If the java application is really meant to be run as a standalone application, there is nothing wrong with using System.exit. in this case, setting an exit value is probably the easiest (and also most used) way of communicating failure or success to the parent process.

如果 Java 应用程序真的打算作为独立应用程序运行，那么使用System.exit. 在这种情况下，设置退出值可能是向父进程传达失败或成功的最简单（也是最常用）的方式。

回答by joev

I agree with the "throw an Exception" crowd. One reason is that calling System.exit makes your code difficult to use if you want other code to be able to use it. For example, if you find out that your class would be useful from a web app, or some kind of message consuming app, it would be nice to allow those containers the opportunity to deal with the failure somehow. A container may want to retry the operation, decide to log and ignore the problem, send an email to an administrator, etc.

我同意“抛出异常”人群。一个原因是，如果您希望其他代码能够使用它，调用 System.exit 会使您的代码难以使用。例如，如果您发现您的类在 Web 应用程序或某种消息消费应用程序中很有用，那么让这些容器有机会以某种方式处理故障会很好。容器可能想要重试操作、决定记录并忽略问题、向管理员发送电子邮件等。

An exception to this would be your main()method; this could trap the Exception, and call System.exit()with some value that can be recognized by the calling process or shell script.

一个例外是你的main()方法；这可能会捕获异常，并System.exit()使用一些可以被调用进程或 shell 脚本识别的值调用。

回答by djechlin

System.exit()will block, and create a deadlock if the thread that initiated it is used in a shutdown hook.

System.exit()如果启动它的线程在关闭挂钩中使用，则会阻塞并创建死锁。

回答by Thomas L?tzer

I think throwing an exception is what you should do when something goes wrong. This way, if your application is not running as a stand-alone app the caller can react to it and has some information about what went wrong. It is also easier for debugging purposes because you as well get a better idea about what went wrong when you see a stack trace.

我认为抛出异常是出现问题时应该做的事情。这样，如果您的应用程序不是作为独立应用程序运行的，则调用者可以对其做出反应并获得一些有关出错的信息。出于调试目的也更容易，因为当您看到堆栈跟踪时，您也可以更好地了解出了什么问题。

One important thing to note is that when the exception reaches the top level and therefore causes the VM to quit the VM returns a return code of 1, therefore outside applications that use the return code see that something went wrong.

需要注意的一件重要事情是，当异常到达顶层并因此导致 VM 退出时，VM 会返回返回码 1，因此使用该返回码的外部应用程序会看到出现问题。

The only case where I think System.exit() makes sense is when your app is meant to be called by applications which are not Java and therefore have to use return codes to see if your app worked or not and you want those applications to have a chance to react differently on different things going wrong, i.e. you need different return codes.

我认为 System.exit() 有意义的唯一情况是当您的应用程序打算由非 Java 应用程序调用时，因此必须使用返回码来查看您的应用程序是否正常工作，并且您希望这些应用程序具有有机会对不同的错误做出不同的反应，即您需要不同的返回代码。

回答by Outlaw Programmer

Our company's policy is that it's OK (even preferred) to call System.exit(-1), but only in init() methods. I would definitely think twice before calling it during a program's normal flow.

我们公司的政策是可以（甚至更喜欢）调用 System.exit(-1)，但只能在 init() 方法中。在程序的正常流程中调用它之前，我肯定会三思而后行。

回答by jjnguy

Throwing exceptions is the best way to send information about a certain error up and out of the app.

抛出异常是将有关某个错误的信息向上和向外发送到应用程序的最佳方式。

A number doesn't tell you as much as:

一个数字并不能告诉您：

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

(or something close to that)

（或接近的东西）

回答by Philip Reynolds

It can be dangerous / problematic in web servlet environments also.

在 web servlet 环境中它也可能是危险的/有问题的。

Throwing an Exception is generally considered the other alternative.

抛出异常通常被认为是另一种选择。

回答by Joel Coehoorn

It's frowned upon for normalexits. If "not everything is going according to plan", then System.exit is fine.

正常退出是不受欢迎的。如果“并非一切都按计划进行”，那么 System.exit 就可以了。

Update: I should add that I assume your '1' has meaning that is documented somewhere.

更新：我应该补充一点，我假设您的“1”的含义在某处有记录。

回答by Franz D.

I feel impelled to add some salt of mine too. This is a great question that always pops up when I write an application.

我也觉得有必要加一些我的盐。这是一个很好的问题，在我编写应用程序时总是会弹出。

As everyone here seems to agree, you should be careful using System.exit(), and if possible, use exceptions. However, System.exit()still seems the only way to return basic informations to the system, and thus required if you want to make your application scriptable. If you don't need that, just throw an exception and be done with it.

正如这里的每个人似乎都同意的那样，您应该小心使用System.exit()，如果可能，请使用异常。但是，System.exit()似乎仍然是将基本信息返回给系统的唯一方法，因此如果您想让您的应用程序可编写脚本，则需要这样做。如果您不需要它，只需抛出异常并完成它。

But if (and only if) your application is single-threaded, then it's fine to use it -- it's guaranteed that no other stuff is going in, and no resources are open (at least if you consistently use the try-with-resourceidiom, which I'd highly recommend as it also makes the code cleaner and more compact).

但是如果（且仅当）您的应用程序是单线程的，那么使用它就可以了——可以保证没有其他东西进入，并且没有资源打开（至少如果您一直使用try-with-resource成语，我强烈推荐它，因为它也使代码更简洁、更紧凑）。

On the other hand, as soon as your application creates any kind of thread that may write resources, System.exit() is a total "no, no", because it can (and, with time, will) corrupt data.

另一方面，只要您的应用程序创建任何类型的可以写入资源的线程， System.exit() 就完全是“不，不”，因为它可以（并且随着时间的推移会）破坏数据。

To be able to use a multi-threaded and scripted application and still guarantee the data integrity, my best solution so far is to save any resource-modifying thread you create (for example by consistently using a factory method which adds the thread to the list), and also installing a shutdown hook that cleanly ends each thread by interrupting and joining it. As the shutdown hook is also called by System.exit(), this will guarantee (minus programming errors) that no thread is killed in mid-resource writing.

为了能够使用多线程和脚本化应用程序并仍然保证数据完整性，到目前为止我最好的解决方案是保存您创建的任何资源修改线程（例如，通过始终使用工厂方法将线程添加到列表中)，并安装一个关闭钩子，通过中断和加入它来干净地结束每个线程。由于关闭钩子也被调用System.exit()，这将保证（减去编程错误）在中间资源写入中没有线程被杀死。

Oh yes, maybe I shouldn't even mention it, but: never, EVER, use that horrible System.halt()method. It just shoots the VM in the head and doesn't call any shutdown hook.

哦，是的，也许我什至不应该提及它，但是：永远，永远，使用那种可怕的System.halt()方法。它只是在头部射击 VM 并且不调用任何关闭钩子。