Is System.exit(0) really that dangerous?

Question

An application background service updates sqlite database. Therefore my activities are becoming outdated. Activity intents also contain outdated params so onCreate, onResume will crash the application. An easiest solution is to restart whole application. I don't want to add IFs to all onCreate, onResume methods in all activities to handle one special case.

I noticed that ACRA has following code executed after an exception has been handled.

android.os.Process.killProcess(android.os.Process.myPid());
System.exit(10);

However many people discourage use of System.exit(0). Is System.exit(0) really that dangerous for an Android application data integrity? Of course my code will close the database before existing.

Update:

I known how to use finish(), content providers, send broadcasts, read many answers here on SO, etc. However each of these approaches requires additional thousands lines of code. I implemented solution with System.exit(0) in ten minutes. The restart is so fast that it is indistinguishable from ordinary startActivity action. The db update/restart is done after longer user inactivity so the app is already suspended by the system. My app doesn't require real time syncing. During tests the application behaves correctly. This is quick and dirty solution.

Therefore I asked the question about possible side effects of System.exit(0). Not how I can do the design differently. I know that current design is not perfect.

Answer 1

System.exit(0) is an artifact from Java runtime, it isn't meant for Android. So in any cases using it would be worst solution.

Why don't you use Activity.finish() gracefully?

If you terminate the process you are living in, you'll loose most of the caching and restart time (~resume in the eyes of the user) for it next time will be higher.

Read more in Activity Lifecycle documentation on Android Developers.

Answer 2

Killing the process will not clean up any registered resources from outside the process. BroadcastReceivers, for example. This is a leak and the device will tell you as much.

You really shouldn't be updating the database schema from a background service. Do it when your activities resume.

If you are just updating your data, resuming an activity should validate the data specified by the Intent and tell the user if, for example, Item X is no longer there.

Answer 3

No tool is that dangerous if used carefully and for a specific, well thought off purpose.

However, In your case I do not believe System.exit() is the right way to go. If your application depends on data from a database, create a background service (or a few, depending on what you need) that will inform your application of changes and update the data. It is, in my opinion the right way to handle changes.

As for scenarios when you want to use System.exit() I personally sometimes use it when I can't recover from a critical error and no graceful degradation is possible. In those cases it is better to force all resources associated with your application to cease rather than just leave loose ends tangling around. To clarify, you should always use error handling before doing anything radical. Proper error handling is often the way to go.

But this is a very delicate topic and you are likely to receive quite a few diverging answers.

Answer 4

Therefore my activities are becoming outdated.

Use a ContentProvider and ContentObserver (or the Loader framework), or use a message bus (LocalBroadcastManager, Otto, etc.) to update the activities in situ.

Activity intents also contain outdated params so onCreate, onResume will crash the application

Copy the relevant "params" to data members of the activities. Update those data members as needed (e.g., from the handlers from the message bus-raised events). Hold onto that data as part of your instance state for configuration change (e.g., onSaveInstanceState()). Use this data from onCreate(), onResume(), etc.

An easiest solution is to restart whole application

It is not easiest, if you value your users, as your users will not appreciate your app spontaneously evaporating while they are using it. Do you think that Gmail crashes their own app every time an email comes in?

Next, you will propose writing a Web app that uses some exploit to crash the browser, because you cannot figure out how to update a Web page.

I noticed that ACRA has following code executed after an exception has been handled.

A top-level exception handler is about the only sensible place to have this sort of code, and even there, the objective is for this code to never run (i.e., do not have an unhandled exception).

Answer 5

There's an existing answer HERE that might give you some help as to why people say it's bad to use System.Exit().