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.
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.
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.)