2015-01-20 11:53 GMT+01:00 Claude Heiland-Allen
[...] But for the second bug, the only way to tell if the glGetShader call failed and left memory unchanged is by checking the GL errors within the binding. I doubt shaderVar will be used in an inner loop so the performance hit should be acceptable.
Again, there is no need for the binding to check anything, the general contract is: If before any call there are no registered errors, nothing bad will happen. Randomly inserting some checks in some arbitrary places in the binding to check for application programmer errors is probably not the way to go. There are more than 80 other places in the binding where something similar might happen, why should shader queries be special? And as I've previously mentioned, exceptions generate more problems than they solve IMHO, at least in conjunction with resources and/or mutable state. In a nutshell: If you want to debug your application, regularly check the OpenGL error state, don't expect any kind of error checking being done for you. And more often than not, even disable those error state checks in the final product for performance reasons.