Re: [PyOpenGL-Users] Re: Have exceptions terminate glutMainLoop (Tarn Weisner Burton)

[Frederic G. <fr...@sc...>]

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