DirectX 10 - determining if hardware device is available

Question

I am writing an offline renderer using SlimDX and Direct3D 10 that will need to be run on machines without graphics cards (servers). On these machines, I'll be using the WARP software renderer.

Is it possible to tell if a hardware device is present without throwing an exception in SlimDX? Currently I'm having to do this:

            try
            {
                Device device = new Device1(DriverType.Hardware, deviceCreationFlags,
                    FeatureLevel.Level_10_1);

                return device;
            }
            catch (Direct3D10Exception)
            {
                return null;
            }

And then create a WARP device if null is returned.

However, each time the exception is thrown, it breaks Visual Studio, which is annoying, and it doesn't seem like I should be catching an exception to determine if a feature is available.

Any way to do this?

Answer 1

In general you can use SlimDX.Configuration.ThrowOnError to almost-globally enable or disable exceptions. You can also set up more complex exception exclusions via SlimDX.Configuration.AddResultWatch.

You cannot, however, prevent SlimDX from throwing exceptions of a constructor (by design). This is because that's the only way to signal failure of a construction aside from constructing an object in a zombie state (which is ugly). The static method Device.CreateWithSwapChain should be usable for constructing your device without throwing (if you disable exceptions). If this doesn't work, please file a bug on the SlimDX issue tracker.

You are correct that it's generally preferable to avoid relying on exceptions for flow control (that is, it's better to be able to ask if something will fail than to have to try it and wait for it to fail, although this is not always possible). SlimDX should support this and if not, it's a bug.

As an aside, you probably have "break on throw" enabled in Visual Studio via the Debug -> Exceptions menu. You can configure how VS reacts to exceptions from that window -- unchecking everything will prevent the debugger from triggering a breakpoint when an exception is raised.

Answer 2

Why not? Exceptions are how you signal error conditions in objects. If a constructor fails, throwing an exception is the only way to signal that failure.

You ask the Device constructor to create a D3D10 device. If no such device exists, what should it do? Create a broken Device object that you can't use, which you have to check to see if it is a working? That's basically assuming that your users will properly code the proper fallbacks into their applications. That's a recipe for disaster; it's much better to use an exception to force the user to code fallbacks, rather than hope that they'll do the right thing.

As for "breaking Visual Studio", I have never seen VS "break" under throwing an exception. What kind of breakage are you experiencing? VS will only halt if the exception goes uncaught. Maybe you're not catching the right type of exception?