Re: [PyOpenGL-Users] Have exceptions terminate glutMainLoop

[Richard J. <ric...@op...>]

On Mon, 8 Oct 2001 00:36, Tarn Weisner Burton wrote:
> Because of the mechanics of the callback execution model we can't pass
> exceptions through it.  For consistency I think that any change in callback
> behavior should apply to all callbacks, not just GLUT callbacks embedded in
> glutMainLoop.  In fact, the exception behavior really has nothing to do
> with glutMainLoop since the change actually occurs in the C callback which
> executes the user's Python callback.

That's how I understand it.


> Because of the execution model of callbacks it's better to think of a
> callback as a separate thread of execution which the main thread waits on.

Yech. Sorry, but yech :)

Callbacks != threads in my mind. 


> In Python's threading model, an unhandled exception in a child thread would
> never cause the parent thread to terminate.  Instead Python would print a
> traceback and terminate the child thread.
>
> In the current setup it's still possible to do what Richard wants to do by
> having the user supply their own try blocks.  Which brings up the point,
> that user's should be providing a try block anyway.  The current
> implementation is only the bare minimum needed to make sys.exit work.

Sorry, but I believe this is completely around the wrong way. I'll be 
perfectly happy to trap any exceptions that I expect, but the unexpected 
ones, I want them to kill the program. That is, if my program doesn't know 
how to deal with a certain situation, it should be terminated, rather than 
just bumbling along, possibly causing damage along the way! I think it's the 
height of ugliness to have to wrap all my callbacks in an extra try/except to 
deal with this.


    Richard