It's very useful; I've long done the same thing. Though - you do need to do something so you can examine the error value. Even though OpenGL's error enum is terribly vague, most functions can produce more than one type of error. It's nice to be able to see what the value was, even if only to verify your assumption that what's obviously the case is indeed actually happening. Store the value somewhere global so you can examine it in the debugger when the program's stopped, or (if you have such a thing) use some fancier assert macro that prints out the problem values.

Also look up GL_ARB_debug_output - https://www.opengl.org/registry/specs/ARB/debug_output.txt. I don't remember this ever telling me anything terribly useful for debugging, but I did get a couple of perf hints from it... anyway, it's vendor-specific, so on OS X, maybe it will help.

(BTW - if you ever end up using Direct3D on Windows, be sure to activate the debug runtime. Compare and contrast.)

I put a simplified version in the article to make it simple, but the macro I actually use in my games is slightly more advanced, and will output more informations about the error and its context.

Ah, right! - my first version was just the assert, and it was working fine until one day I ended up on a wild goose chase because I was certain it had to be GL_INVALID_OPERATION. But in fact... it was GL_INVALID_ENUM :) So I just thought I'd save somebody a couple of minutes.

A common pattern in embedded C is to use something like "goto fail" instead of assert, wrap your function calls in this sort of macro, and then do error handling in one place at the end of the function.

Apparently Apple is unaware of this technique...

I use that style too, but I've not found it useful for OpenGL. When you're developing your product, you want every OpenGL error to explode in your face, so you know it happened. In your final build, you probably won't ever check, because... well, what will you do if something happens? OpenGL errors are much more like ENOMEM than they are like ENOENT, and if you get one in production, you're basically stuffed. The best thing you can do is just carry on and hope that the driver ignores it correctly! (One advantage to working on code whose primary purpose is merely to display something on the screen: you can do stuff like that, and it's OK.)

There are exceptions to this general rule, and sometimes you do need to use glGetError in the normal run of things, and take action based on the result. But they are very much exceptions.

Okay, so as someone who is ramping up on C where would I go to learn all these common patterns? I could start going through github repos and start reading code but this seems very inefficient and I might pick up something that is actually a bad technique.

I like Zed Shaw's Debug Macros. Actually his whole book is great.

http://c.learncodethehardway.org/book/ex20.html

Another useful OpenGL macro, at least for me, is this one:

    #define GLSL(str) (char*)"#version 330\n" #str

It basically enables you to embed quick snippets of GLSL inside your C code, instead of using concatenated strings. Example:

    char* fragShader = GLSL(
      in vec3 uv;
      out vec4 color;
      uniform sampler2DArray tex;
      void main()
      {
        // Comments work too
        color = texture(tex, uv);
      }
    );

In Sublime Text you even get code completion and color highlighting, since GLSL and C look so alike.

I believe it might work for OpenCL Kernels too.

The only downside is that it doesn't add line breaks by itself (hence the "#version 330\n", which requires a line break), so GLSL Compilation errors aren't as useful.

(Source: https://open.gl/geometry )

If you use C++ you might be interested in glbinding (https://github.com/hpicgs/glbinding). It allows you to define an after callback which can be defined as a function that checks for errors. It also has a few other improvements over GLEW.

Why is it wrapped in a do{}while(0); ?

See e.g http://stackoverflow.com/questions/257418/do-while-0-what-is...