When should one let an application crash because of an exception in Java (design issue)? [closed]

Question

In most cases, it is possible to catch exceptions in Java, even unchecked ones. But, it is not necessarily possible to do something about it (for example out of memory).

For other cases, the issue I am trying to solve is a design principle one. I am trying to set-up a design principle or a set of rules indicating when one should give up on an exceptional situation, even if it is detected in time. The objective is trying to not crash the application as much as possible.

Has someone already brainstormed and communicated about this? I am looking for specific generic cases and possible solutions, or thumb-rules.

UPDATE

Suggestions so far:

• Stop running if data coherency can be compromised
• Stop running if data can be deleted
• Stop running if you can't do anything about it (Out of memory...)

• Stop running if key service is not available or becomes unavailable and cannot be restarted

• A method/service should check whether it can perform its duty from a stable state, if not it should inform the user (log) and do nothing

• If application must be stopped, degrade as gracefully as possible
• Use rollbacks in db transactions
• Customized exceptions can be used to give tips about how to solve the situation by handler
• Log as much relevant information as you can
• Notify the developers

• Preserve state and data coherency as much as you can

• Quick fixes can be harmful, when debugging, better let the application crash and analyze in details what caused it

Answer 1

The creators of Java and .Net decided to use the TYPE of a thrown exception object to determine when it should be caught and when it should be considered resolved, a design decision probably motivated by the way C++ handles exceptions. Although C++ exception handling was in many ways an improvement over what existed before, its use of the type of an exception object as the primary means for determining what exceptions were caught was not one of its better features.

Because exception catching is controlled by exception type, there is no standard means for exception to indicate whether a failed operation has altered the state of any objects in the system, or whether the failure was caused by objects being in a corrupted state (as opposed to a state which, while it may be unexpected by the caller and not compatible with the passed-in parameters, would otherwise be considered by the called method to be perfectly legitimate). In many cases, if in response to a user request the system calls a method which tries to do something and can't, but the method does not adversely affect the state of any object and the problem isn't caused by an object having a corrupted state, it may often be best to simply inform the user that the requested action could not be performed and continue on. Unfortunately, there's no way of distinguishing the 'harmless' exceptions of the types indicated above, from those which indicate severe system-wide problems. While 99% of exceptions will probably be relatively harmless, a small fraction will be caused by conditions which could cause corruption to open documents. If an open document has been corrupted, it may be better for a program to instantly crash outright than to let it replace a good copy on disk with a corrupted one.

If throwing custom exceptions, it may be possible to include properties in the exception type which would allow code to somewhat more usefully decide what should be done about an exception. Unfortunately, many exceptions that get thrown, whether harmless or not, will not include such properties.