DirectX and Exceptions

Assuming you're talking about native C++ exceptions (rather than Managed/C# or SEH):

1) A few do. But only as part of their *internal* error handling. This internal handling usually involves returning an failure HRESULT from the function you called.

2) Since they're internal, they're subject to change whenever the there's an SDK update, and so no documentation exists for them.


Return values are the *only* way you should be handling errors from DirectX when using native C/C++.

Additionally, unless you need to check for a specific error (e.g. D3DERR_DEVICENOTRESET), always use the FAILED()/SUCCEEDED() macros rather than doing things like "if (hr!=D3D_OK)...".

Well granted... however when writing functions in C++ if you define a function such as this:

void IntializeD3D() throw() // nothrow

And you call a DirectX function within the funciton above that throws an exception it contradicts the definition of the function because it is not allowed to throw... thus the exception either has to be caught in InitializeD3D or

unexpected

will be executed which will cause the program to abort (with no doubt several memory leaks).

Quote:

Original post by JClayton Well granted... however when writing functions in C++ if you define a function such as this: void IntializeD3D() throw() // nothrow And you call a DirectX function within the funciton above that throws an exception it contradicts the definition of the function because it is not allowed to throw... thus the exception either has to be caught in InitializeD3D or unexpected will be executed which will cause the program to abort (with no doubt several memory leaks).

AFAIK the throw()/__declspec(nothrow) restrictions only apply to child/callee functions that are directly under your control.

If a DirectX function throws *and catches* an exception internally, then by the time the function returns control to your application, the stack has been fully unwound to a state as if the exception had never occurred.

Ok... I'm clear on that now. As a client of DirectX I don't care if the API throws and catches exceptions internally (as long as they are caught :P ). All I wanted to know is if the DX functions threw exceptions that were meant to be handled by clients similar to std functions/operators.

Quote:

Original post by JClayton Ok... I'm clear on that now. As a client of DirectX I don't care if the API throws and catches exceptions internally (as long as they are caught :P ). All I wanted to know is if the DX functions threw exceptions that were meant to be handled by clients similar to std functions/operators.

Nah, don't worry about that - DirectX can be used from C, which doesn't support exceptions. Looks damn ugly though [grin]

Can someone elaborate why not to use exceptions with DirectX?

I've got this (nasty) habit of initialize all my subsystems in the class constructor - whereas returnvalues are impossible - so exceptions is the way to halt the execution.

Renderer* pRender = new Renderer(...);if(pRenderer->Init() == false) {/*something's amiss*/}// the Renderer::Init() is a superfluous method in my opinion

Renderer* pRender = new Renderer(...);// this is teh shit - the pRenderer is constructed AND initialized

but this is as I stated earlier, my PERSONAL OPINIONS.

Quote:

Can someone elaborate why not to use exceptions with DirectX?

Did anybody say that? I regularly do, and a lot of others too.

Quote:

Original post by Metus Can someone elaborate why not to use exceptions with DirectX?

You are free to use exceptions (C++, SEH, your favorite other variety) in your code but the unmanaged DirectX APIs are written such that you should *never* see an exception cross the boundary of the API. As mentioned, some of the DirectX APIs might use exceptions internally but such API entry points catch the exceptions and return failure return values. Exceptions are not used because DirectX has to support languages and compilers that don't implement exceptions the same way as Visual C++ (which itself has changed implementations over the years).

Paul Bleisch (MS)

exception-handling is slowing down your code, i think this is the reason why there is no exception thrown by DX, cause games need faster code than an office application

also i think the exception handling in c++ is poorly solved, best exception handling i've ever work with was the ada exception handling

[Edited by - Becko on March 25, 2005 1:31:47 AM]

Quote:

Original post by Becko exception-handling is slowing down your code, i think this is the reason why there is no exception thrown by DX, cause games need faster code than an office application

Exceptions are only thrown on exceptional cases, they typically aren't thrown 99% of the time - If your app/game is getting slowed down by exceptions, then most probably you're using them incorrectly.

Quote:

also i think the exception handling in c++ is poorly solved, best exception handling i've ever work with was the ada exception handling

Never tried Ada. How does it work?