Exception Handling and GLEventListener -- looking for advice

OpenGL Development JOGL Development
#1

Hi,

I decided to sit down over the past couple of days and figure out a way to handle all exceptions that could come out of my rendering code in such a way that I could get a little bit of feed back in a dialog. I’ve never really had to mix swing EDT things with error handling and jogl things before so I’ve been hitting some rough bits and was looking for advice.

My first approach was to do something like this:


	@Override
	public void display(GLAutoDrawable glDrawable) {
		if (exceptionDialog != null) {
			if (exceptionDialog.isFinished()) {
				System.exit(1);
			}
		} else {
			try {
				gl = glDrawable.getGL();

				gl.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT);
				gl.glLoadIdentity();

				for (Renderer r : currentContext.getRenderers()) {
					camera = r.getCamera();
					r.initialize(this);
					r.renderBefore(this);
					r.render(this);
					r.renderAfter(this);
				}
			}
		} catch(Throwable t) {
			exceptionDialog = new ExceptionDialog(t);
			exceptionDialog.launch();
		}
	}

Actually that is my second attempt. My first was to make the dialog modal but I ended up having the swing EDT keep running (I Think?) and it would keep hitting display and keep hitting the exception. With this approach it will keep calling display, but if there is a dialog it won’t do my rendering stuff.

So, eventually I learned about the setUncaughtExceptionHandler on Thread objects and decided I kind of liked that instead of having a try-catch block so now I have:


	@Override
	public void display(GLAutoDrawable glDrawable) {
		if (exceptionDialog.isRunning()) {
			if (exceptionDialog.isFinished()) {
				System.exit(1);
			}
		} else {
			gl = glDrawable.getGL();

			gl.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT);
			gl.glLoadIdentity();

			for (Renderer r : currentContext.getRenderers()) {
				camera = r.getCamera();
				r.initialize(this);
				r.renderBefore(this);
				r.render(this);
				r.renderAfter(this);
			}
		}
	}

	@Override
	public void init(GLAutoDrawable glDrawable) {

		exceptionDialog = new ExceptionDialog();
		Thread.currentThread().setUncaughtExceptionHandler(exceptionDialog);

So my question now becomes: Is this the right approach? Is setting an exception handler on the EDT dangerous?

On a somewhat related but not quite so much note: is there a way to completely stop the canvas from being updated so that when I catch an exception I stop the canvas and don’t have to do checking in my display for the exception dialog? A quick and dirty (it seems) way to do it is to remove the canvas from the window.

Thank you very much,
Eugene

#2

UncaughtExceptionHandler is mainly there to catch Exceptions that would normally get lost without a trace and destroys the thread in which it occured. It gets invoked right before the Thread dies. With a try/catch block you can move on.

It shouldn’t (by design) be used for handling expected behaviour, where you’d normally use try/catch.

It’s like using System.addShutdownHook(Thread) to launch your RenderThread after you exited the main-method. :wink:

#3

What you’re doing looks alright to me: you’ve got a check before the rendering part to decide whether or not to go on, and in the event that you choose not to, you do a System.exit(). Trying to maintain the rendering window after an exception might not be such a great thing to do; what’s to prevent the error from occurring again once you put the OpenGL canvas back?
If anything, I would’ve tried placing this checking sooner in the OpenGL thread, but I guess this is the first place you can do it when using JOGL’s GLEventListener and Animator classes.

So long as it does what you want it to do and it conforms with your own style of programming, what more can you ask for? :slight_smile:

#4

Well I don’t mean it to be the only exception handling of course :slight_smile:

Its mostly there as a last resort sort of thing like if in some odd case i get a null pointer or some such none of those methods explicitly throw anything so its pretty much only runtime exceptions I’m catching.

Being somewhat of a threading noob I was unsure if monkeying with this feature with respect to swing and jogl would cause untold headaches.

I don’t really want to keep the canvas around, its just that at the moment its hard to get rid of it – the event listener doesn’t really know about the canvas at all… I’m still trying to think of a clean way to get rid of the system.exit, but still make my app quit(at least the graphics for now) - but that’s a completely different problem that I have to deal with :slight_smile:

Thank you very much for the feedback. Sitting here all alone you sometimes wonder if you’re doing things that are … sane? :slight_smile:

Eugene