At 01:06 PM 11/5/99 -0700, you wrote:
>The semantics are more consistent this way, but I'm not too crazy about
>terminating the app if one of these functions is called in an unsupported
>context. I would prefer to simply set a GL_ERROR when possible (i.e. when
>a context is bound). But I can live with it either way. I'm against just
>leaving the behavior undefined or noop.
I think we have a fundamental difference in philosophy with regards to an
implementation's obligation to buggy applications. Calling an extension
pointer in a context which does not support that extension is in my opinion
a severe error, and is likely to be caught early during development. As
Jon said, allowing some relatively innocuous behavior such setting an error
(seriously, most developers never check) makes it less obvious to the
developer that such a severe error has occured, and can lead to an extended
debugging session which is avoidable given a less tolerant implementation.
My first choice is to let the application crash (I promise you, the
developer will fix this quickly) and my second choice is to generate an
XError (as you know, this terminates X applications w/o an error handler).
Note that I am not arguing against the merits of the GL error mechanism; I
appreciate the wisdom of its design, as a hardware implementation cannot be
expected to bring down a running application. But unless we believe a
device independent dispatch mechanism is likely to ever appear in silicon,
I believe we are on solid ground in mandating a more severe reproach.
