Best practices for trapping a unhandle runtime Exception for JAVA on the Android os?
During a process that I have firing off during a e3roid scene population on the android I keep coming across exceptions that I want to completely trap. Perhaps I need to create a back exception tracker that i can transverse through at my leisure instead of an immediate dialogue that takes away a user experience.
W/dalvikvm( 9540): threadid=1: thread exiting with uncaught exception (group=0x2
aac87c8)
E/AndroidRuntime( 9540): FATAL EXCEPTION: main
E/AndroidRuntime( 9540): java.util.ConcurrentModificationException
E/AndroidRuntime( 9540): at java.util.ArrayList$ArrayListIterator.next(Ar
rayList.java:573)
the whole app dies with an exception dialogue.. I would love to be able to trap the ConcurrentModificationException from a global scope so that if such a event happens due to unknown circumstances the whole app does not get disposed..
** EDIT **
during this block getting fired off during a onSceneTouchEvent
try {
postUpdate(new AddShapeImpl(scene, onX, onY));
} finally {
}
seems I am firing off the block too fast I think. I need to slow things down.
* Follow Up *
I seemed to of solved the problem.. I did one of these...
if ( ballspawning == false)
try {
Log.v(DEBUG_TAG, "onSceneTouchEvent 1-1");
addnewball(scene, onX, onY);
Log.v(DEBUG_TAG, "onSceneTouchEvent 1-2");
} finally {
}
you will see that after I put in a ballspawning boolean flag and a secondary procedure that I pass my spawning values was so golden... i made it a field and it gets set at the end of my iteration and checked before the transverse of the list happens.. whoo hoo!! soo sweet!
no real need for global trapping.. just good old debugging. but I still would love to implement the global handler of all errors. TODO
I have erupted the concurrent error again..
screenshots
Debug Msgs
Another Occurrence
- Follow Up 2 * Another One
screen shot 4
almost narrowing down culprit
I tried to catch the ConcurrentModificationException with a
void uncaughtException(Thread t,
Throwable e){
Log.v(DEBUG_TAG, "uncaughtException **********");
Log.v(DEBUG_TAG,"thread " + t + " Throwable" + e.toString());
}
as you can see in the last screenshot that the above method never gets called.
The ConcurrentModificationException crashs the app to a exception dialogue..
** Follow up **
I have added
public class LauncherActivity extends E3Activity implements UncaughtExceptionHandler ,FPSListener,SceneUpdateListener
and during runtime the extra Unimplimented Method
@Override
public void uncaughtException(Thread t,Throwable e) {
Log.v(DEBUG_TAG, "uncaughtException **************");
Log.v(DEBUG_TAG,"thread " + t + " Throwable" + e.toString());
}
and still no exception trapping...
I also added
newThread.setUncaughtExceptionH开发者_Go百科andler(new Thread.UncaughtExceptionHandler(){
@Override
public void uncaughtException(Thread t, Throwable e) {
Log.v(DEBUG_TAG,"*************** ERROR! An exception occurred in " + t.getName() + ". Cause: " + e.getMessage());
}
});
newThread.start();
and no still no trapping...
ahhh
WHoo hoo!!
Just caught the exception!! check out the screen shot... you will see the !!!!!!
http://img17.imageshack.us/img17/135/concurrentmodificatione.png
Caught Exception
Thx all that made me work hard at getting to the bottom of java exception handling!!
Excellent Resource
I trapped the Concurrent problem by
removing the...
public class LauncherActivity extends E3Activity implements UncaughtExceptionHandler ,FPSListener,SceneUpdateListener
that I had to original... with no UncaughtExceptionHandler implementation
and added a class that was greatly detailed by Johnny Lee. blog.dimond.de/?p=63
Sweet stuff really.
Use Thread.setUncaughtExceptionHandler
:
It takes an Thread.UncaughtExceptionHandler
as argument which is an interface of one method: uncaughtException(Thread t, Throwable e)
.
From the documentation:
Set the handler invoked when this thread abruptly terminates due to an uncaught exception.
Needless to say however, you're obviously better of fixing the exceptions at their sources. ;-) I do however use this construct my self for sending error reports in case of unforeseen errors.
I think you would rather make sure that the ConcurrentModificationException isn't happening at all.
It is an exception that arises when you are iterating a Collection
with its Iterator
. While you are iterating, you cannot be updating the collection. Here is a scenario where it would arise:
List<Integer> intList = new ArrayList<Integer>();
for (int i=0; i < 100; ++i) {
intList.add(i);
}
int addValue = 1000;
for (Integer i: intList) {
if (i%10 == 0) {
//get ready for ConcurrentModificationException...
intList.add(++addValue);//this is bad, because we are iterating over intList.
}
}
This would cause a ConcurrentModificationException, because we are iterating over a list and attempting to add to it while that iteration is happening.
精彩评论