Richard Jones wrote:
> On Wed, 10 Oct 2001 07:00, Frederic Giacometti wrote:
> > pyopengl-users-request@... 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.
Usually, when mixing python with one or more other system, the rules are as
a) When returning to Python:
check for error condition in returning system
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
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.