Highlighted

Android ANEs and Exceptions / Throwables

Community Beginner ,
Jun 10, 2014

Copy link to clipboard

Copied

Firstly, when I create a simple FREFunction where I deliberately try to create an error, say

       

        Log.d("CrashyFunction", "Entering");

       

        String NULL_STRING = null;

        Log.d("CrashyFunction", "NULL_STRING: '" + NULL_STRING + "'");

        Log.d( "CrashyFunction", NULL_STRING.toUpperCase() );

        Log.d("CrashyFunction", "Exiting");

       

       

In LogCat, I see "Entering", and "NULL_STRING: 'null'", but nothing else.  No crash, no stacktrace, just process halted and everything else seemingly swallowed.  Is that the case?  Every exception or throwable in the Android world is just swallowed, and we're not notified about it at all?  Or am I building my ANEs weird that's setting this behaviour, or is there some way I can set this so that errors don't get swallowed?

Secondly, one of our main bugs is weirdness of incompatible versions of Android and local & push notifications.  We get an ok stacktrace from Google Play, but we'd much prefer to be handling that stuff ourselves, so what we have at the start of our LocalBroadcastReceiver is a call to Thread.setDefaultUncaughtExceptionHandler, to handle any uncaught errors, process them, get the stacktrace, and send it back up the line with a "dispatchStatusEventAsync" with the FREContext we created in our main ANE entry point.

Unfortunately, while it's a shared codebase, in this situation it's a separate thread because the process is started with ":remote" appended to the process ID, and because of that, the FREContext is actually null.  It exists in the main thread, but not here, so therefore we can't communicate back to the app.  Is there any solution to this, or is this just the way it is?

TOPICS
Performance issues

Views

109

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more

Android ANEs and Exceptions / Throwables

Community Beginner ,
Jun 10, 2014

Copy link to clipboard

Copied

Firstly, when I create a simple FREFunction where I deliberately try to create an error, say

       

        Log.d("CrashyFunction", "Entering");

       

        String NULL_STRING = null;

        Log.d("CrashyFunction", "NULL_STRING: '" + NULL_STRING + "'");

        Log.d( "CrashyFunction", NULL_STRING.toUpperCase() );

        Log.d("CrashyFunction", "Exiting");

       

       

In LogCat, I see "Entering", and "NULL_STRING: 'null'", but nothing else.  No crash, no stacktrace, just process halted and everything else seemingly swallowed.  Is that the case?  Every exception or throwable in the Android world is just swallowed, and we're not notified about it at all?  Or am I building my ANEs weird that's setting this behaviour, or is there some way I can set this so that errors don't get swallowed?

Secondly, one of our main bugs is weirdness of incompatible versions of Android and local & push notifications.  We get an ok stacktrace from Google Play, but we'd much prefer to be handling that stuff ourselves, so what we have at the start of our LocalBroadcastReceiver is a call to Thread.setDefaultUncaughtExceptionHandler, to handle any uncaught errors, process them, get the stacktrace, and send it back up the line with a "dispatchStatusEventAsync" with the FREContext we created in our main ANE entry point.

Unfortunately, while it's a shared codebase, in this situation it's a separate thread because the process is started with ":remote" appended to the process ID, and because of that, the FREContext is actually null.  It exists in the main thread, but not here, so therefore we can't communicate back to the app.  Is there any solution to this, or is this just the way it is?

TOPICS
Performance issues

Views

110

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Jun 10, 2014 0

Have something to add?

Join the conversation