C++ exceptions

Started by
52 comments, last by Hodgman 8 years, 2 months ago
I know it wasn't pro-return codes/anti-exception.

Simply pointing out that if you're going to make a dynamically linked library, C++ exceptions cannot cross the API boundary, so they aren't really an option for APIs.
Advertisement

Just an illustration that while having error reporting for logic errors is theoretically nonsense, in practice it's common as a debugging tool.

It isn't only a debugging tool. The DirectX implementation cannot trust its callers: logically incorrect API usage (for example drawing commands involving vertex data, frame buffers, shaders,textures etc. that don't exist or are in a bad or uninitialized state) is possible, and the best way to deal with it is reporting the caller mistake and containing the corruption, not silently drifting into dangerous and inconvenient undefined behaviour.

Omae Wa Mou Shindeiru

Just an illustration that while having error reporting for logic errors is theoretically nonsense, in practice it's common as a debugging tool.

It isn't only a debugging tool. The DirectX implementation cannot trust its callers: logically incorrect API usage (for example drawing commands involving vertex data, frame buffers, shaders,textures etc. that don't exist or are in a bad or uninitialized state) is possible, and the best way to deal with it is reporting the caller mistake and containing the corruption, not silently drifting into dangerous and inconvenient undefined behaviour.

Note that this philosophy has been left behind with D3D12 (and Mantle, and Vulkan, and every native games-console API ever). Incorrect API usage is now undefined behaviour, unless you've initialized the library in a special development mode (which won't work on customer's PC's). The philosophy of strongly worded API specs and dire consequences for misuse has a very long history in console games development.

And (IMHO) a program that's using a native API incorrectly deserves to crash, or suffer memory corruption, or worse. Having native APIs attempt to tolerate incorrect usage, turns those unacceptable patterns into de facto accepted patterns... which gives birth to Windows compatability modes (which deliberately enable bugs for old, incorrect programs to rely on), or Internet Explorer (self explanatory).

IMHO, having a development mode that fails quickly and loudly upon undefined behavior, and a slim API with no pollution from logic-error handling is far nicer than the situation that D3D11 or HTML suffer.

Sorry for the slight necro, but this blog post on error handling is a must read:
http://joeduffyblog.com/2016/02/07/the-error-model/

This topic is closed to new replies.

Advertisement