Handling of errors

Is there any central way to detect errors in your application in order to make an easy and non-techie way to help users report them?

For example if an exception is thrown in the LWJGL thread at the moment the application just exits. I’d like to make things somewhat more interactive…

Yeah just override handleError in SimpleApplication

4 Likes

Damnit, I knew there must be a way and I even looked at the SimpleApplication javadoc and the error handling tutorial before I posted but couldn’t see it. I think I was looking for “exception” not “error”.

Thanks :slight_smile:

P.S. I’ll add something to the wiki.
P.P.S. Worked out why I missed it, I looked in SimpleApplication not Application… and its only in the “inherited from” section there which combined with my looking for something with exception in it led to the confusion.

Right, added

Advanced Error Handling

When an uncaught exception reaches certain parts of the jME3 system then the default response is to log the error and then exit the application. This is because an error happening every frame will rapidly fill logs with repeated failings and potentially mask or over-write the original cause of the problem or even the application may continue for a while and then suffer other errors caused by the first and make the root cause hard to determine.

This behaviour can be partially modified by overwriting the method handleError in SimpleApplication, for example to display a custom message to users, or to provide users with information on how to report a bug or even to change the way that the error is logged.

To https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:advanced:logging

2 Likes

I think you meant “overriding” and not “overwriting”.

1 Like

I did, fixed it thanks.

Ok, some follow on questions.
Basically I’m trying to work out what the options are if a CTD exception happens. The handleError method tells me that the exception has happened, ideally I then want the display window to close (especially if it was fullscreen) and a swing frame to popup with the error report and an option to send the error report to me that could then make a HTTP post request to my website with the crash report. To keep things as robust and platform independent as possible I’d like to do all this inside the one jvm rather than trying to spawn a new process etc.
handleError tells me that an error has happened but is the shutdown etc behaviour controllable? or is system.exit() or similar getting called whatever I do? Can I somehow cause the rendering thread and 3d scene etc to disappear but still keep the java running and show a new swing window?

Thanks,
Z

If you don’t call super.handleError() then I’m pretty sure the app will not shut down unless you shut it down.

If you don’t call super.handleError() then I’m pretty sure the app will not shut down unless you shut it down.
I think it does, its delivered after the fact, in the SDK I have to put a try/catch around the whole update stuff to prevent it from stopping. You could relaunch it though after you found out about whats the issue, you gotta check what you have to handle when your AppStates or w/e get restarted.

Well there are two things here, there is the big A Application which is the LWJGL stuff, the display, etc, etc.

Then there is the little a application which is the actual Java program running in the JVM.

In the case of a CTD I’m quite happy for the big A Application to exit since I won’t be trying to resurrect it…in fact I want it to exit so that for example full screen windows go… however I want the little a application to keep running so it can then fire up a swing window.

But I’m not sure how to do that or if its even possible :slight_smile:

Yeah it is. In handleError() you are basically the last thread thats running, so just spawn a new one (e.g. start the application again) or do whatever you have to do in that call. Java will only exit when all threads are finished. So its the capital A Application that stops, not necessarily the java app, thats just happening because if you don’t do anything, all threads have come to an end after handleError is finished.

That’s funny. I’m sure I remember that when I didn’t call super.handleError() that I got log error spam and my app kept running.

handleError is useless if you can’t “HANDLE” the error and continue.

[java]Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
public void uncaughtException(Thread thread, Throwable thrown) {
listener.handleError("Uncaught exception thrown in "+thread.toString(), thrown);
}
});[/java]

Set the default handler invoked when a thread abruptly terminates due to an uncaught exception, and no other handler has been defined for that thread.

“When it terminates”, I guess that means it doesn’t continue ^^

Ah, maybe that is not the only place that calls handleError().

There is some reason I have code to call super.handleError(). I even have code after it to detect when handleError() didn’t cause the app to terminate it so that I can do it forcefully. Maybe it was one of those nights of trying the shotgun approach to problem solving, though.

And one thing is true, if you have non-daemon threads hanging around then the app won’t close normally even if handleError() is called. I sort of recall that there is some path that also forces the app closed but I’ve left enough Mythruna clients as zombies to know that the app won’t System.exit() under some circumstances.

…these means that another thread (like AWT) can still be running and doing stuff even if the JME app dies. In theory.

Ok, thanks. With that info in mind I’ll try and put something together this week and see what I can come up with.

hello;
Not be like overriding handleError in SimpleApplication
Thank you very much Rohans