When Should One Call glGetError?

Question

glLoadIdentity says

GL_INVALID_OPERATION is generated if glLoadIdentity is executed between the execution of glBegin<

Answer 1

I'm not sure if your question is about when you can call glGetError if inside glBegin/End or whether it's a more general question about glGetError usage in general. So I'll answer both.

What you can do between glBegin and glEnd is very limited. This is on purpose, as you put the GL in a very specific mode - in the middle of a Draw. As such, anything that does not relate directly to per-vertex attributes is simply invalid. Even a glGetError is invalid in that context.Try and think of glBegin+all the GL calls in between+glEnd as a single Draw call to the GL, that helps get closer to what the GL really does anyways.

Now, you should never really have a GL error triggered while inside the Begin/End pair if you stick to the simple rule to only call attribute methods (glNormal, glTexCoord, glColor, glSecondaryColor, glIndex, glMultiTexCoord, glVertexAttrib, glVertex and a couple others). Anything else will trigger an error. (err... well, glMaterial is a bit of an exception. It works, but its usage has been discouraged)

If your question is when you can call glGetError when the error was triggered inside a Begin/End pair, ChrisF answered in a comment: after the glEnd call.

Now, in a broader sense, use glGetError only as a debugging tool. My personal bias is twofold:

• check glGetError once per frame to be sure there is no error
• wrap most GL calls with a macro that can check the GL error code, and only turn it on when the per-frame check fails.

Of course, since the attribute methods can be called outside a Begin/End pair, it's a bit tricky to get them right. But in practice, those methods never fail anyways, so I don't bother to macro-check them.

A tidbit of trivia: the GL API was originally designed so that the client implementation could actually not know whether there was an error at the call site. E.g. if the GL was actually implemented in a remote machine (like in the SGI days), a call to, say, glTexEnv with a target not of GL_TEXTURE_ENV could simply be added to the command buffer, and no error would be recorded at that point.

If you then called glGetError, the client side would then have to flush the command buffer to the GL server, wait for the commands that are buffered to be processed, get the error code back, and return the appropriate error code to the application.

If this sounds heavy, that's because it was. This was the main reason why not each call was returning an error code, by the way, and why calling glGetError was only considered ok for debugging purposes. These days, most GL implementations are handling all the state management in the same process, so as I said, it's really trivia for most users.

Last, whenever I'm talking about Begin/End, I feel I need to say that you should probably look at not using it at all. It's about the worst performing way to Draw with GL.

Answer 2

Some philosophies of coding expect every program to check for every possible error, and appropriately handle those errors. Yet, following one of those philosophies requires a lot of extra code, and can significantly slow a program. In practice, I only use glGetError when I'm diagnosing a problem, or write some code that has a significant possibility of failing and an appropriate action after the error.

In the first case, diagnosing a problem, I use one of two strategies. Because OpenGL doesn't record new errors until glGetError is called, I can either check for errors once each time through my main loop. That tells me the first error, which I then track down, and hopefully fix. The other strategy I use when I've narrowed down to some problematical code, but I'm not sure which call is causing the problem. After each gl... call outside a glBegin . . . glEnd block I'll call glGetError, and report any errors. This will tell me exactly which gl... call is causing the problem, and hopefully start me on the path to a fix.

In the second case, defensively programming for a likely error, I'll call glGetError to clear the error flag, make my other gl... call(s), then call glGetError. Then I take whatever action is required to deal with whatever glGetError reports.

Answer 3

Normally you should call glGetError after every other gl... call as one of the effects of the call is to clear the error from the stack (from the MSDN):

When an error occurs, the error flag is set to the appropriate error code value. No other errors are recorded until glGetError is called, the error code is returned, and the flag is reset to GL_NO_ERROR.

However, if you have calls wrapped in glBegin and glEnd call glError after the glEnd. This should return you the correct error code (if there was one) and clear the error stack.