This page is about how to improve error handling in OpenSG.


Current status

  • Many (if not all) rendering errors are ignored and the app keeps running.
  • Many classes are good at reporting failures/warnings to the log, so you get _some_ indication most of the time (apart from the user seeing the scene fail to render properly).
  • NullPtr return on failure when using i/o. (usually no info on what went wrong)

Possible error handling solutions

(these are all standard methods)

  • Throw exception (Preferred, can't be silently ignored
  • GetLastError?() (Ignorable, easy to add simple check on startup and/or per frame. Not finegrained enough if user-code doesn't add them everywhere.)
  • return SUCCESS/FAIL. (Very easy to ignore, even by accident. Also horrible to implement nicely)

Desired detect/report policy in OpenSG code

  • Every fatal error ought to call osgFatalError() which might throw.
  • Regular errors (that lead to unexpected results) ought to be flagged as such (too many are just warnings today).
  • Adding a log-callback for fatal/error is of course also one solution... but it is brittle (not all error reporting might be done yet) and it seems to be the wrong place for this.

Suggested User settiable error handling strategies

  • KeepRunnning (today)
  • ThrowException (to abort and catch in debugger or terminate app)
  • TerminateApp (for systems without exception support)
  • UserCallback (allow user full freedom)

Specific cases

Some specific cases where the current situation isn't satisfactory:

  • GLSL shader error.
  • Warnings are output as warnings. This is nice because the shader compiles and executes anyway.
  • Errors are also warnings, which is horrible since the scene renders but with shaders disabled.
  • (FBO)Viewport missing camera/root/background. (These are warnings, they ought to be errors)
  • OpenGL errors are spewed to the log. No way for the app to know about it (other than scanning the log).
  • SSM camera has near/far equal to zero/inf. (This just ought to be ignored rather than getting a spewing of warnings in the log)
  • Win32Window just warns if activate fails, and then proceeds to crash further down the road. Here we most likely _need_ to abort rendering. (It's a fatal error)

There's also been references to errors in the socket/clustering system on the mail list, where this might apply. (I don't know enough about that to comment here. Contributions welcome.)



  • I'm a strong proponent of signalling errors in an un-ignorable way (i.e. throwing exceptions). At least, I'd like to have that option. The rest of our app is pretty solid at the moment but not w.r.t. the rendering.
Last modified 7 years ago Last modified on 01/17/10 01:11:44