Why "unhandled exceptions" on android tracked in coroutine?

[cNoNim]

Can someone explain history of that code?

appcenter-sdk-unity/Assets/AppCenter/Plugins/AppCenterSDK/Crashes/Shared/Crashes.cs

Line 88 in 0da3d12

UnityCoroutineHelper.StartCoroutine(SendUnhandledExceptionReports);

I was seeing in git blame:

at some point, coroutine was creating in subscription to unhandled exceptions, then in this commit #187 coroutine creation was moved to exception handling

And now we produce new coroutines for each exception... any reasons for that?

And main question is coroutine creation and execution does not works in multithreaded application, which purpose of using queue with locking?
Why exception handling tracked in coroutine and only for android?

This behaviour complicates solutions like #242.

In teory we want set some properties in some place before exception throwing and clear them after. But async exception tracking make that painfull.

[Jamminroot]

Hey, @cNoNim, thanks for getting in touch.
Please, give us some time to investigate it.

[Jamminroot]

Ok, I've got an update on the problem.
It appears, that at that time we had to run the code in the main thread, since other approaches ended up with error messages of exceptions thrown not being quite clear and understandable.

[cNoNim]

I understand reason for use coroutine, but its not android only problem, and now solution broken, cause StartCoroutine, FindObjectOfType and new GameObject() can (or should) be used from main thread only.

[annakocheshkova]

@cNoNim as mentioned, calling TrackException without async block / not on main thread causes errors. That's because creating JNI objects should be done either on main thread or using AndroidJNI.AttachCurrentThread() / DetachCurrentThread() (see documentation) which has already been tried and didn't work in our case.
I just verified this behaviour and got

 E/zygote: JNI ERROR (app bug): accessed stale Local 0x9  (index 0 in a table of size 0)
 A/zygote: java_vm_ext.cc:534] JNI DETECTED ERROR IN APPLICATION: use of deleted local reference 0x9

However, if you want, you can use TrackException the way it is convenient for you, by turning off Crashes.ReportUnhandledExceptions(false); .