I wanted to get your opinions on the usage of Thread.setDefaultUncaughtException. Here is my scenario:
I have an activity that starts up a LocalActivityManager, which in turn starts up several Activities and pulls in their decor views and puts them into current activities view. However, there is the case that a particular activity might be a rogue activity and will cause the entire host activity to crash. One such case is the subactivity causes an OutOfMemory exception due to excessive Bitmap allocation. My thought was that I could make my host application implement UncaughtExceptionHandler and assign the Thread's default uncaught exception handler to it. In the handler, I log that an exception occurred, and the application can continue for very short period of time, but then I get an ANR (Application Not Responding) obviously because I am catching a pretty critical exception and not doing anything about it other than logging. Optimally, I would like to shut down the offending view that caused the exception, but I am not sure how to get that view when I am already in the last stage of trying to deal with the exception (the uncaught exception handler callback). What can I do if I want to keep the architecture of the LocalActivityManager that I currently have in place, but harden my code against contributing activities that do not cooperate or cause my host activity to run out of memory? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
