Difference Between Finish() and System.Exit(0)

Difference between finish() and System.exit(0)

Actually there is no difference if you have only one activity. However, if you have several activities on the stack, then:

• finish() - finishes the activity where it is called from and you see the previous activity.
• System.exit(0) - restarts the app with one fewer activity on the stack. So, if you called ActivityB from ActivityA, and System.exit(0) is called in ActivityB, then the application will be killed and started immediately with only one activity ActivityA

What is the difference between `finishAffinity();` and `finish()` methods in Android?

finishAffinity() : finishAffinity() is not used to "shutdown an application". It is used to remove a number of Activities belonging to a specific application from the current task (which may contain Activities belonging to multiple applications).

Even if you finish all of the Activities in your application, the OS process hosting your app does not automatically go away (as it does when you call System.exit()). Android will eventually kill your process when it gets around to it. You have no control over this (and that is intentional).

finish() : When calling finish() in an activity, the method onDestroy() is executed this method can do things like:

• Dismiss any dialogs the activity was managing.

• Close any cursors the activity was managing.

• Close any open search dialog.

Difference between killing a process and System.exit(0);

System.exit(1);

Usually a non-zero error status indicates that the program ended abnormally and

int id= android.os.Process.myPid();

Process is Tools for managing OS processes.

android.os.Process.killProcess(id);

Kill the process with the given PID. Note that, though this API allows us to request to kill any process based on its PID, the kernel will still impose standard restrictions on which PIDs you are actually able to kill. Typically this means only the process running the caller's packages/application and any additional processes created by that app; packages sharing a common UID will also be able to kill each other's processes.

Difference between exit(0) and exit(1) in Python

0 and 1 are the exit codes.

exit(0) means a clean exit without any errors / problems

exit(1) means there was some issue / error / problem and that is why the program is exiting.

This is not Python specific and is pretty common. A non-zero exit code is treated as an abnormal exit, and at times, the error code indicates what the problem was. A zero error code means a successful exit.

This is useful for other programs, shell, caller etc. to know what happened with your program and proceed accordingly.

What are the differences between calling System.exit(0) and Thread.currentThread().interrupt() in the main thread of a Java program?

Summary

1. thread.interrupt() does not stop a thread. It is used for coordination in multi-threaded programs. Don't use it unless you know exactly what you do.
2. Throwing a RuntimeException will (usually) terminate the thread but not necessarily the program.
3. System.exit(int) almost always terminates the program and returns a status code.
4. In unusual situations, System.exit(int) might not actually stop the program. Runtime.getRuntime().halt(int) on the other hand, always does.

Thread Interruption

I'm afraid your first sentence is wrong. Thread.currentThread().interrupt() does not stop the thread or the program.

Interrupting a thread is a way to signal that it should stop, but this is a cooperative effort: The code in the thread is supposed to check the interrupted status from time to time and (in most cases - but even this is only optional) should stop if is has been interrupted. If it doesn't do that nothing will happen.

Specifically, interrupting a thread (any thread, include the currently executing one) will only set the interrupted flag. Certain methods in the standard library will throw an InterruptedException, but this is also just a way to signal that the thread has been interrupted. What should be done in such a situation is up to the code running in that thread.

Here are the relevant parts from the Java Concurrency in Practice book by Brian Goetz:

Thread provides the interrupt method for interrupting a
thread and for querying whether a thread has been
interrupted. Each thread has a boolean property that
represents its interrupted status; interrupting a thread sets
this status.

Interruption is a cooperative mechanism. One thread cannot
force another to stop what it is doing and do something
else; when thread A interrupts thread B, A is merely
requesting that B stop what it is doing when it gets to a
convenient stopping point if it feels like it.While there
is nothing in the API or language specification that demands
any specific application level semantics for interruption, the
most sensible use for interruption is to cancel an activity.
Blocking methods that are responsive to interruption make it
easier to cancel long running activities on a timely basis.

Exceptions and System.exit(int)

The Javadoc of System.exit(int) says:

Terminates the currently running Java Virtual Machine. The argument serves as a status code; by convention, a nonzero status code indicates abnormal termination.

So calling exit() will (almost) definitely stop your program. In contrast to throwing a RuntimeException (or an Error), this can not be caught somewhere down the call stack and it does also not depend on whether there are other threads running. On the other hand, an uncaught exception terminates the thread in which it was thrown, but if there are any other (non-daemon) threads, the program will continue to run.

Another difference to throwing an Exception is that exit() will not print anything to the console (as does an uncaught exception) but instead makes the program return a specific status code. Status codes are sometimes used in shell or batch scripts but other than that, they are not very useful.

Runtime.halt(int)

Finally (for completeness' sake), I'd like to point out a third possibility to exit a Java program. When System.exit(int) is called (or the program ends in some other way), the runtime does some cleanup work before the Java Virtual Machine is halted. This is described in the Javadoc of Runtime.exit(int) (which is called by System.exit(int):

The virtual machine's shutdown sequence consists of two phases. In the first phase all registered shutdown hooks, if any, are started in some unspecified order and allowed to run concurrently until they finish. In the second phase all uninvoked finalizers are run if finalization-on-exit has been enabled. Once this is done the virtual machine halts.

If any shutdown hook or finalizer is prevented from completing, for example because of a deadlock, the program might never actually exit. The only method that guarantees that the JVM halts is Runtime.halt(int):

This method should be used with extreme caution. Unlike the exit method, this method does not cause shutdown hooks to be started and does not run uninvoked finalizers if finalization-on-exit has been enabled.

When should we call System.exit in Java

System.exit() can be used to run shutdown hooks before the program quits. This is a convenient way to handle shutdown in bigger programs, where all parts of the program can't (and shouldn't) be aware of each other. Then, if someone wants to quit, he can simply call System.exit(), and the shutdown hooks (if properly set up) take care of doing all necessary shutdown ceremonies such as closing files, releasing resources etc.

"This method never returns normally." means just that the method won't return; once a thread goes there, it won't come back.

Another, maybe more common, way to quit a program is to simply to reach the end of the main method. But if there are any non-daemon threads running, they will not be shut down and thus the JVM will not exit. Thus, if you have any such non-daemon threads, you need some other means (than the shutdown hooks) to shut down all non-daemon threads and release other resources. If there are no other non-daemon threads, returning from main will shut down the JVM and will call the shutdown hooks.

For some reason shutdown hooks seem to be an undervalued and misunderstood mechanism, and people are reinventing the wheel with all kind of proprietary custom hacks to quit their programs. I would encourage using shutdown hooks; it's all there in the standard Runtime that you'll be using anyway.

---

Related Topics