Replace "handle" with "tryHandle" for uncaught exceptions

[dkhalanskyjb]

This is a draft because it is a big binary-compatibility-breaking change. I was hoping to start a discussion about this so that we could evolve this to some form that's acceptable to merge.

I find this to be a much clearer mental model.

• A handler can decide if it can process this particular exception.
• A handler can be in an invalid state, and it can now pass handling the uncaught exception to the system, without making additional noise.
• Before this change, there are two types of exception handlers:
  • Those that are used as coroutine context elements. If a coroutine context element processes an exception successfully, the system is not notified about them.
  • Those that are used as services. These are just notified about exception, they are not considered to be consuming them. I guess this was done for the sake of Android's pre-handler.

If we forget about backward compatibility, I'm certain this is the way to do it, but I don't see a good way to make this change while staying backward-compatible.

[elizarov]

Btw, it looks like it can be made backwards compatible with JDK8 default interface methods.

[qwwdfsad]

If we forget about backward compatibility, I'm certain this is the way to do it

I tend to agree with this statement. Great job with figuring it out!

I would refine the API a bit to avoid situations where ordering is important by prohibiting user-defined platform exception handlers using any trick from our book (e.g. by introducing internal subinterface).

The good news are, @udalov is going to figure out jvm-defaults policy for Kotlin libraries migration soon, so we can definitely leverage it and migrate to tryHandleException