{"action":"created","issue":{"url":"https://api.github.com/repos/BoltsFramework/Bolts-Android/issues/48","labels_url":"https://api.github.com/repos/BoltsFramework/Bolts-Android/issues/48/labels{/name}","comments_url":"https://api.github.com/repos/BoltsFramework/Bolts-Android/issues/48/comments","events_url":"https://api.github.com/repos/BoltsFramework/Bolts-Android/issues/48/events","html_url":"https://github.com/BoltsFramework/Bolts-Android/issues/48","id":55199330,"number":48,"title":"Add \"unobserved\" exception handling","user":{"login":"grantland","id":277030,"avatar_url":"https://avatars.githubusercontent.com/u/277030?v=3","gravatar_id":"","url":"https://api.github.com/users/grantland","html_url":"https://github.com/grantland","followers_url":"https://api.github.com/users/grantland/followers","following_url":"https://api.github.com/users/grantland/following{/other_user}","gists_url":"https://api.github.com/users/grantland/gists{/gist_id}","starred_url":"https://api.github.com/users/grantland/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/grantland/subscriptions","organizations_url":"https://api.github.com/users/grantland/orgs","repos_url":"https://api.github.com/users/grantland/repos","events_url":"https://api.github.com/users/grantland/events{/privacy}","received_events_url":"https://api.github.com/users/grantland/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/BoltsFramework/Bolts-Android/labels/enhancement","name":"enhancement","color":"84b6eb"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-01-22T19:45:02Z","updated_at":"2015-01-22T21:42:08Z","closed_at":null,"body":"> An “unobserved” exception is one that’s stored into the task but then never looked at in any way by the consuming code.  There are many ways of observing the exception, including Wait()’ing on the Task, accessing a Task<TResult>’s Result, looking at the Task’s Exception property, and so on.  If code never observes a Task’s exception, then when the Task goes away, the TaskScheduler.UnobservedTaskException gets raised, giving the application one more opportunity to “observe” the exception.  And if the exception still remains unobserved, the exception escalation policy is then enabled by the exception going unhandled on the finalizer thread.\r\n\r\n> ...exceptions indicate something has gone wrong, and crashing helps developers to immediately identify that the application has entered an unreliable state.\r\n\r\n(Source: http://blogs.msdn.com/b/pfxteam/archive/2011/09/28/task-exception-handling-in-net-4-5.aspx)\r\n\r\nIn .NET, \"unobserved\" exceptions will bubble up and intentionally crash the application. This would be a useful feature to allow developers to be notified (via a crash) of an \"unobserved\" exception since it means their application has entered an unreliable state.\r\n\r\nSince this would be a breaking change, it might be worthwhile to disable this feature by default and require it to be explicitly turned on by developers."},"comment":{"url":"https://api.github.com/repos/BoltsFramework/Bolts-Android/issues/comments/71104718","html_url":"https://github.com/BoltsFramework/Bolts-Android/issues/48#issuecomment-71104718","issue_url":"https://api.github.com/repos/BoltsFramework/Bolts-Android/issues/48","id":71104718,"user":{"login":"JosephEarl","id":2513147,"avatar_url":"https://avatars.githubusercontent.com/u/2513147?v=3","gravatar_id":"","url":"https://api.github.com/users/JosephEarl","html_url":"https://github.com/JosephEarl","followers_url":"https://api.github.com/users/JosephEarl/followers","following_url":"https://api.github.com/users/JosephEarl/following{/other_user}","gists_url":"https://api.github.com/users/JosephEarl/gists{/gist_id}","starred_url":"https://api.github.com/users/JosephEarl/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JosephEarl/subscriptions","organizations_url":"https://api.github.com/users/JosephEarl/orgs","repos_url":"https://api.github.com/users/JosephEarl/repos","events_url":"https://api.github.com/users/JosephEarl/events{/privacy}","received_events_url":"https://api.github.com/users/JosephEarl/received_events","type":"User","site_admin":false},"created_at":"2015-01-22T21:42:07Z","updated_at":"2015-01-22T21:42:07Z","body":"Some thoughts based on https://www.securecoding.cert.org/confluence/display/java/MET12-J.+Do+not+use+finalizers\r\n\r\n> 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.\r\n\r\nThis 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.\r\n\r\n> 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.\r\n\r\nSurely we'll have to lock in some manner around the list of handlers?\r\n\r\nThe `finalize()` method should also be made final to prevent incorrect overriding.\r\n"}}