I’m wondering how to do the exception handling in an OpenGL programm. If i do a normal application with the vcl, i’m always handle my exceptions with the
try… catch… finally… blocks, and so… So, is it usefull or recommended to use these Exception handlers also in OpenGL???
(quiet this kind of exception handling is a C++ feature, isnt it?)
thx HECK
try/catch/throw is C++, OpenGL is C, so no, it won’t work with OpenGL.
But nothing stops you from using exception handling for your own code though. You just can’t use it for detecting/handling OpenGL-related errors.
OpenGL is C? <says to an off-camera person and mutters quitely> what kind of game is he playing at?
noooo, no no no. opengl is no such thing. opengl is just an api… it has C bindings, but it also has java, ada and fortran bindings. it’s an api, and not a langauage damnit! <said like doctor whatshisname from star trek>
cheers,
John
OpenGL implementations are often written in c…
Not sure if that is what Bob meant, though.
You can use GLGetError() to see if a GLError has been registered. Check the red book pg. 563.
Funk.
yer, so? C is compiled into machine code, so the fact they WERE C is irrelevent. In fact, some compilers—like the mighty GNU power horse—compile the source language into an intermediate code of their own design, before writing an assembler/compiler to translate the intermediate code into the target machine code. so… even something like the gnu ada compiler compiles into the SAME gnu object langauge as the gnu c compiler (as does the gnu fortran compiler)… so, what’s the difference? there is no difference.
at the end of the day, opengl is NOT a language. it doesn’t have a set of EBNF rules describing its syntax, a list of rules describing its semantics (although it has a man page for its prototypes=). it’s just not a langauge.
cheers,
John
true, true…
I wasn’t saying OpenGL is a language, just trying to clear up some confusion, guess I failed. he he…
Funk.
oh! and another thing! you can implement exception LIKE things in C with the longjmp mechanism. =)
oh, and exception handling in C++ shouldn’t affect things, greatly… uhm. no. it shouldn’t. but you have to appreciate that the opengl context is quite independent of what your program is doing, so you better make sure that the opengl context is happy. for example, if you did this:
glBegin(GL_LINES);
glVertex2f(…);
try {
doSomethingWhichMightCauseAnException();
glVertex2f(…);
} catch(int ackfatalmycodejustdied) {
glVertex2f(…);
}
glEnd();
then what is drawn on screen will be different if your exception is taken, or not. As you would excpet, that is, so long as all your glVertex calls are different.
cheers,
John
john,
I think what Bob meant is that it is unlikely that doing:
try
{
glCommand(GLparam xxx);
}
catch(xxx)
{
}
will ever lead you to the “catch” part…
And as he said, this is simply because it is very unlikely that you will find a “throw” in the implementation of “glCommand” if this glCommand has been implemented using C.
And yes, I know, you can catch C exception using C++…
Regards.
Eric
Uhm, yeah sure. OpenGL is not C, sorry. It has C bindings.
I DO know OpenGL is not a langeuage itself. Even though I might have expressed myself the other way, it was not meant to. What I was trying to point out is that OpenGL is not object oriented, and does not use any C++ specific features. And the API is therefore is more like C than C++. The C-bindings that is.
And the example Eric gave about using try/catch, was about what I meant. Sure, you CAN code that way, but you shouldn’t expect the catch-part to be executed that much.
Refer to khronos documentation for error handling via the callback mechanism.
Although you are able to write a try { } catch { } block around your C++ code, OpenGL calls do not throw C++ exceptions, but instead they do accumulate errors that can be either manually read, or you can setup and use an error callback using glDebugMessageCallback(). Out of the box, OpenGL does not throw exceptions, but you could emulate exceptions from within such a callback by throwing a custom exception from within the callback.
See Khronos Documentation at the Wiki : Catching errors (the easy way)
"The debug output feature provides a simple method for your application to be notified via an application-defined message callback function when an OpenGL error (or other interesting event) occurs within the driver. Simply enable debug output, register a callback, and wait for it to be called with a DEBUG_TYPE_ERROR message.
use glGetError() calls around your application to catch and localize the causes of OpenGL errors (and the need to conditionally compile them into debug builds to avoid the performance hit in optimized builds). The feature can even ensure that message callback functions are invoked on the same thread and within the very same call stack as the GL call that triggered the GL error (or performance warning).
A simple example showing how to utilize debug message callbacks (e.g. for detecting OpenGL errors):
void GLAPIENTRY MessageCallback( GLenum source, GLenum type, GLuint id, GLenum severity, GLsizei length, const GLchar* message, const void* userParam ) { fprintf( stderr, “GL CALLBACK: %s type = 0x%x, severity = 0x%x, message = %s\n”, ( type == GL_DEBUG_TYPE_ERROR ? “** GL ERROR **” : “” ), type, severity, message ); } // During init, enable debug output glEnable ( GL_DEBUG_OUTPUT ); glDebugMessageCallback( MessageCallback, 0 );"
Note that you’re replying to a 20 year old thread.
The callback must have C linkage, so throwing an exception is undefined behaviour. Also, unless GL_DEBUG_OUTPUT_SYNCHRONOUS is enabled, the thread in which the callback is invoked is unspecified.
This issue is not about whether or not it is in the same thread as the application, debugMessageCallback is invoked by many different sources, such as source API, shader compilation, etc. The issue is about receiving information back from OpenGL about errors.
The callback void GLAPIENTRY debugMessageCallback(GLenum source, GLenum type, GLuint id, GLenum severity, GLsizei length, const GLchar* message, const void* userParam)
does not need C linkage. I have defined one in C++, and you can most definitely throw from here. And it is in the same thread as the application.
From the point of view of the specifications (C, C++ and OpenGL), it most definitely does need C linkage. From the point of view of whether it works in practice, that depends upon the compiler, the platform, and the OpenGL implementation (all of which need to allow it, in the sense of offering no impediment to it working).
sorry dude but it works just fine for me,.im not interested in whether or not you think it needs C linkage, as i have it working against a C++ class method just fine, so i’m not interested in what you believe as it works just fine here. from the point of view of the specification you supply glDebugMessageCallback with some function pointer whether it be C or C++, so im not sure why you keep talking about C linkage? all of my code is 100% C++ compiled visual studio. The openGL API is just a glad wrapper to exposed DLL functions.
anway the whole topic is about responding to errors in C++ with openGL its got nothing to do with C linkage, so i am not going down a rabbit hole with you discussing general specifications.
Then I guess you don’t care about writing cross-platform programs. Because “works just fine here” has never been a successful way to write anything that you expect to work on something not “here”.
Um, no it’s not. OpenGL doesn’t need GLAD, and OpenGL is not a “glad wrapper” at all. GLAD is merely a tool for loading OpenGL function pointers. And it’s not the only such tool; you could even write your own loader.
Actually, it does. You cannot throw a C++ exception through a function with C linkage, as it has absolutely no idea what to do with that. At least, not in a portable way.
So your answer of “throwing a custom exception from within the callback” is not portable. Maybe it works on VS, but this forum needs answers that aren’t bound to a single platform.
Again, this is a thing that happens “here”, but as GClements pointed out, it is something a user can manipulate.
I honestly have no idea what that image is supposed to prove. I never denied that the code as you described it worked on your implementation, in your programs, compiled by your compiler with the specific settings you used. So proving that it “works here” changes nothing.
The point is that it is not portable. This is a fact, and posting images of a debugger will not change this fact.
If you swipe a candy bar from a store, you’re still breaking the law even if you get away with it. And a store with better security may catch you next time, or maybe the same store with a different manager.
i thought throw was part of the C++ standard and therefore portable? forgive me if i am wrong…
the thread was to help someone with their question about accessing openGL errors, and they had no knowledge of glDebugMessageCallback to use as a way to access openGL error information?
I do no see anywhere showing that the discussion needs to be about portability?
is glDebugMessageCallback also not available on other API interfaces?
“I honestly have no idea what that image is supposed to prove. I never denied that the code as you described it worked on your implementation, in your programs, compiled by your compiler with the specific settings you used. So proving that it “works here” changes nothing.”
The image is code working with C++, and utilising a throw within a glDebugMessageCallback cannot you see it? There is nothing platform specific here it is just C++ and OpenGL.
“The point is that it is not portable . This is a fact, and posting images of a debugger will not change this fact.”
Where is the fact that it is not portable? sorry i do not concur with your sweeping observation without any valid reasoning.
“If you swipe a candy bar from a store, you’re still breaking the law even if you get away with it. And a store with better security may catch you next time, or maybe the same store with a different manager.”
Bizarre analogy, I am writing software not stealing chocolates!
Throwing through a C function is not something C++ has any concept of. And passing OpenGL a pointer to a function with C++ linkage is not part of the OpenGL specification of any version.
That you manage to get away with one of these does not mean that it’s legal, valid code. It just means you got away with it.
