Thread: [PyOpenGL-Users] Re: Have exceptions terminate glutMainLoop (Tarn Weisner Burton)
Brought to you by:
mcfletch
From: Frederic G. <fr...@sc...> - 2001-10-09 21:01:04
|
pyo...@li... wrote: > | But what if glGetError() gets raise in the event loop ? > | Shouldn't this be catched, without regard to the origin of the glError ? > | > | If this were the case, glutMainLoop should also check for glGetError()... > > glutMainLoop does get checked for glGetError, but this check is useless > since glutMainLoop never returns. > > Anyways, the debate is not over glGetError, but Python exceptions. > More precisely, the debate is about mapping Python exceptions with glErrors - Python code is being run under the control of a glut function -. Does anybody knows what happens is a glError is raised by opengl in a glutMainLoop() callback function ? FG |
From: Richard J. <ric...@op...> - 2001-10-09 21:58:47
|
On Wed, 10 Oct 2001 07:00, Frederic Giacometti wrote: > pyo...@li... wrote: > > | But what if glGetError() gets raise in the event loop ? > > | Shouldn't this be catched, without regard to the origin of the glError > > | ? > > | > > | If this were the case, glutMainLoop should also check for > > | glGetError()... > > > > glutMainLoop does get checked for glGetError, but this check is useless > > since glutMainLoop never returns. > > > > Anyways, the debate is not over glGetError, but Python exceptions. > > More precisely, the debate is about mapping Python exceptions with glErrors Not if glutMainLoop can't return those errors, or quit itself because of them. Which it can't. Normally, python exceptions, when unhandled, cause a program to terminate. In pyopengl, they are swallowed. I know of one other system where exceptions are swallowed: Zope. Causes no end of pain and agony because things can get very very strange when exceptions are not allowed to kill things. Richard |
From: Frederic G. <fr...@sc...> - 2001-10-10 16:47:04
|
Richard Jones wrote: > On Wed, 10 Oct 2001 07:00, Frederic Giacometti wrote: > > pyo...@li... wrote: > > > | But what if glGetError() gets raise in the event loop ? > > > | Shouldn't this be catched, without regard to the origin of the glError > > > | ? > > > | > > > | If this were the case, glutMainLoop should also check for > > > | glGetError()... > > > > > > glutMainLoop does get checked for glGetError, but this check is useless > > > since glutMainLoop never returns. > > > > > > Anyways, the debate is not over glGetError, but Python exceptions. > > > > More precisely, the debate is about mapping Python exceptions with glErrors > > Not if glutMainLoop can't return those errors, or quit itself because of > them. Which it can't. > > Normally, python exceptions, when unhandled, cause a program to terminate. In > pyopengl, they are swallowed. I know of one other system where exceptions are > swallowed: Zope. Causes no end of pain and agony because things can get very > very strange when exceptions are not allowed to kill things. > > Richard Usually, when mixing python with one or more other system, the rules are as follows: a) When returning to Python: check for error condition in returning system if error: raise python error clear error in returning system return NULL to python b) When returning from Python: check for python error (PyErr_Occurred()) if python error raised: raise error flag/condition in caller context clear python error Mutatis mutandis... But it's true that it is too often, exceptions and their problems get just ignored, giving place to the 'endless pain and agony' cited above. FG |