RE: [PyOpenGL-Users] Have exceptions terminate glutMainLoop

[Mike C. F. <mcf...@ho...>]

So each handler needs to be something like:

def x( a,b ):
	try:
		try:
			doWhatever
		except (X,Y,MemoryError, IOError): # expected error conditions
			pass
	finally:
		cleanup() # handle restoring state

vs

def x( a,b ):
	try:
		doWhatever
	finally:
		cleanup() # handle restoring state

It's possible to define "safe wrapper" functions that share that
exception-catching code, I suppose.  Sigh.  My reaction is based on my
experiences as a user where, for instance, 3DSMax dumps out because the
dongle got knocked loose, or Tiberean Sun decides to end the whole game
because 1 packet was received too late (timeout exception doesn't get
caught, so the entire program exits, dumping hours of play), or where setup
scripts bomb because a single callback wasn't received due to an unexpected
condition (too many mice on the system, or C drive isn't available, or
sockets can't be initialised).  I suppose those (recent) experiences have
tainted my vision.

I will bow to general opinion on this one, as I can see lots of "rigor"
benefits, but from experience with OpenGLContext using PyGame (where an
exception in a handler actually kicks you out of the main loop), I've not
really found the functionality that pleasant to work with.  I'm not really a
"rigor" programmer, suppose I'll have to learn.

If we are going to raise something, can we raise the last Python exception,
instead of SystemExit?

Dumb question: Can the glut main loop be restarted if I catch an exception
and decide it was unimportant (if I'm getting SystemExit instead of a real
exception, that's kinda hard to determine, of course)?

I don't really like the environmental variables approach. It makes code
harder to share, since code with one assumption won't readily fit into
another.  Rather learn to write straight-jacket code than have a split in
coding styles like that.

Enjoy,
Mike


-----Original Message-----
From: pyo...@li...
[mailto:pyo...@li...]On Behalf Of Richard
Jones
Sent: October 6, 2001 19:05
To: 'PyOpenGL Mailing List'
Subject: Re: [PyOpenGL-Users] Have exceptions terminate glutMainLoop


On Sat, 6 Oct 2001 18:18, Mike C. Fletcher wrote:
> I'm not in agreement regarding the "right way" here.
>
> For instance, if you force an exit on an uncaught exception, then any
> callback raising an exception can cause data loss for the user (a
> spurious/unimportant exception is raised, rather than being able to use

Woah there. I'm of the firm belief that if an exception is not handled in
code, it's never going to be a "spurious/unimportant exception". It is, by
definition, an "exception" to the correct running of the code. It means that
something has happened that the programmer did not expect, and is likely to
cause lots of problems. The Python way of handling exceptions that are not
caught is to terminate the program to avoid complications. Consider that the
exception occurred during processing of the user's data. The
"spurious/unimportant exception" is ignored, and the user is given the
option
to unknowingly save their corrupted data.


> Fail on any exception is nice for scripting/testing environments, but
> kicking out of the whole application in larger projects seems too heavy to
> me.  Would redirecting stderr to a log file work?  I haven't tried it
> lately, but I think it should be able to catch the exception output.

I suggest that the C callback handlers exit when they detect an exception
(the alternative is to quit the gluMainLoop, but we can't do that). As a
trade-off, have the exit behaviour dependant on some environment setting:

  . gluMainLoop(suppress_exceptions=1)
  . gluMainLoopSuppressExceptions
  . os.environ['GLU_MAINLOOP_SUPPRESS_EXCEPTIONS'] = 1


     Richard

_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net
_______________________________________________
PyOpenGL-Users mailing list
PyO...@li...
https://lists.sourceforge.net/lists/listinfo/pyopengl-users