You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 27, 2020. It is now read-only.
This has been a fairly longstanding issue and it can be triggered from both internal SDK code (under rare circumstances) and team code. Generally, if a thread that is not the main OpMode or LinearOpMode thread throws an exception, the entire app will crash to the homescreen and the team will be unable to recover for the rest of the match. This thread can either be started by code written by the team, or an internally such as used in Vuforia or TFLite processing through bugs in the SDK.
One can reproduce this issue with a simple OpMode that looks something like this:
One solution to this issue is simply setting a default exception handler for all threads. [This gist will restart the robot controller on a crash] (https://gist.github.com/guineawheek/ea7390854c3f9ecaca56d6ad1ad630fe), although for different threads different responses may be more appropriate to reduce downtime.
The text was updated successfully, but these errors were encountered:
guineawheek
changed the title
threads that throw unhandled exceptions that are not the main opmode thread irrecoverably crash the RC app
Threads that throw unhandled exceptions that are not the main opmode thread irrecoverably crash the RC app
Jan 8, 2019
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This has been a fairly longstanding issue and it can be triggered from both internal SDK code (under rare circumstances) and team code. Generally, if a thread that is not the main OpMode or LinearOpMode thread throws an exception, the entire app will crash to the homescreen and the team will be unable to recover for the rest of the match. This thread can either be started by code written by the team, or an internally such as used in Vuforia or TFLite processing through bugs in the SDK.
One can reproduce this issue with a simple OpMode that looks something like this:
One solution to this issue is simply setting a default exception handler for all threads. [This gist will restart the robot controller on a crash] (https://gist.github.com/guineawheek/ea7390854c3f9ecaca56d6ad1ad630fe), although for different threads different responses may be more appropriate to reduce downtime.
The text was updated successfully, but these errors were encountered: