Add "unobserved" exception handling about bolts-android HOT 6 CLOSED

How do you propose to tell when a Task goes "away", by using a PhantomReference?

from bolts-android.

I think the C# version uses the destructor on the task to detect when the GC is collecting the task (i.e. there are no remaining listeners for the exception on the task). Same deal here -- use the finalize() method in Java.

from bolts-android.

Some thoughts based on https://www.securecoding.cert.org/confluence/display/java/MET12-J.+Do+not+use+finalizers

Uncaught exceptions thrown during finalization are ignored. When an exception thrown in a finalizer propagates beyond the finalize() method, the process itself immediately stops and consequently fails to accomplish its sole purpose. This termination of the finalization process may or may not prevent all subsequent finalization from executing. The Java Language Specification fails to define this behavior, leaving it to the individual implementations.

This sounds like we cannot make the unhandled exception crash the entire process, only the finalizer thread (or threads) and that (JVM dependent) when that happens the finalizer thread might never re-spawn.

Use of locks or other synchronization-based mechanisms within a finalizer can cause deadlock or starvation. This possibility arises because neither the invocation order nor the specific executing thread or threads for finalizers can be guaranteed or controlled.

Surely we'll have to lock in some manner around the list of handlers?

The finalize() method should also be made final to prevent incorrect overriding.

from bolts-android.

Reviving this. Let's discuss implementation. To get started

Task

void finalize() {
  if (faulted) {
    unobservedExceptionHandler.didNotObserve(exception);
  }
}

How does unobservedExceptionHandler raise the exception?

from bolts-android.

Total shot in the dark but fire off another thread that raises the exception?

In .NET, they trigger this from the TaskExceptionHolder deconstructor: http://referencesource.microsoft.com/#mscorlib/system/threading/Tasks/TaskExceptionHolder.cs

Another solution since finalizer use is very discouraged and has some weird quirks, we can do this in a more Java friendly way by holding a WeakReference to Task exceptions somewhere as well as a reference count of observed exceptions from a scheduled Task and periodically check the exception references and count to see if there were any exceptions that have been GC'd but not observed.

Thoughts?

from bolts-android.

After reading up to grantland's comment, I was thinking of suggesting something akin to .net's TaskExceptionHolder. The holder need only be created when there is an exception, and possibly when it isn't propagate to a continuation task.

As far as exceptions in the GC thread, it would make more sense to pass the an UnobservedTaskException to the Thread.getDefaultUncaughtExceptionHandler(). On Android, the default value will crash the app, but more importantly in my experience it is really common to call Thread.setDefaultUncaughtExceptionHandler() in order to attach logging to unhandled exceptions. Logging unobserved exceptions is more important to me than actually crashing the app. It would also allow library consumers to dictate how they want to respond.

from bolts-android.