1

Is there anywhere I can find documentation on the exception safety levels of different methods in the DirectX 11 API?

Mark
  • 155
  • 3
  • 16
  • If you see it crashing, make sure [constant buffers are aligned properly](https://msdn.microsoft.com/en-us/library/windows/desktop/ff476092.aspx). – CodeAngry Feb 09 '15 at 09:27
  • I'm more thinking about anticipating errors thrown by paths through my code that I hadn't considered. I haven't actually gotten that far yet :) – Mark Feb 09 '15 at 13:43
  • 1
    Well then, no worries. As long as you don't mess up the memory yourself, DX is rock-solid and only throws errors at you, no exceptions! *(pun intended)* :) Just check the HRESULTs and act accordingly. – CodeAngry Feb 09 '15 at 14:00
  • I get a bit OCD about paths through my code is all. I want to minimize my exposure to unknown paths. I'm paranoid about cases where an object might not be initialized, whether that's through improper initialization or through having been uninitialised through some unknown process. I guess this is what proper design combined with thorough testing is for – Mark Feb 09 '15 at 14:29
  • 1
    Use a `ComPtr` for all the interfaces. That way you don't need to worry. Use the WRL one or roll your own *(not trivial)*. Just don't go for naked interface pointers. – CodeAngry Feb 09 '15 at 15:01
  • and then shared_ptr for all my own objects that are used in various places? – Mark Feb 09 '15 at 15:58
  • How you represent your game's object in memory it's your choice. It affects performance **but `unique_ptr` is a start**. Use it to control the objects life span and just pass it around as a pointer. `shared_ptr` is ref-counted. So it's best to have clear ownership and just use pointers to `unique_ptr.get()`. – CodeAngry Feb 09 '15 at 16:06
  • That's what I was doing, unique_ptr within the object owner, then retrieving that for all other objects. I encountered a problem where the objects owner is a collection, unique_ptrs cannot be used in an STL collection as they cannot be copied, which I understand is required for various collection operations – Mark Feb 09 '15 at 16:17
  • It can be moved. With the latest Visual Studio, it'll work OK with virtually all collections. I found a bug when it failed to move couple months ago but it's fixed now. OR just use fixed heap allocations if you know the element counts upfront... It's all a matter of design and needs. – CodeAngry Feb 09 '15 at 16:39
  • Please don't, the comments are useful, at least to me. I could *theoretically* know the element count beforehand, as it is a map for storing meshes. – Mark Feb 09 '15 at 16:41
  • OK. Anyways, keep reallocations to a minimum. If you know the count upfront you can keep the collection container's size fixed. This prevents copies and allows you to pre-design your memory access patterns. – CodeAngry Feb 09 '15 at 16:47
  • I will do, all meshes are loaded at the start of a level and released at the end of the level. – Mark Feb 09 '15 at 16:51

1 Answers1

2

None of the DirectX APIs in C++ will throw C++ exceptions. They won't generate SEH exceptions either unless there's some kind of runtime or user-mode driver bug, or a breakpoint is triggered by the debug runtime.

That's why they all return HRESULTs or void.

In general Direct3D 11 objects follow standard COM lifetime rules based on their AddRef/Release reference counts with the major exception that if the device is fully released, then all device-child objects created from it are immediately invalidated.

Even if not using C++ exception handling, it's good practice to write exception-safe code and using Microsoft::WRL::ComPtr for DirectX 11 interface objects is a good idea--with the caveat that you need to ensure the final device instance itself is released/reset last of course.

Chuck Walbourn
  • 38,259
  • 2
  • 58
  • 81