Daniel:

Sorry, the burrada was mine, I didn´t saw the <- (inverse arrows)... If the surface returns an DDERR_INVALIDPARAMS, it is a design-time error and not a execute-time error. In things that are supposed to work OK, you don´t need a rigid error-system. Let´s say you couldn´t draw a surface, well, anyways, unless it´s lost, you can´t do anything, so why making a big mess of all this? For example, my supposed-to-work-OK functions don´t report errors. Why? Because I can´t do anything. Lost surfaces are recovered in other place, not there. And if I get an DDER_INVALIDPARAMS, I would debug it with log(). I am studying informatic engineering, and I must tell you that we have devoted hours and hours to error-reporting functions, and it´s quite a big problem. If the error is recoverable, handle it. If the error is not recoverable, log() it and continue the program. If the error is critical, well try to log() it, but there´s nothing you can do.

Me canse de escribir en ingles.
Mientras tu funcion "boba" no pueda arreglar el error, salta al padre, que deberia poder, y si no puede, al padre y asi sucesivamente... Si de ultima no podes, bueh.... Hay errores que no se pueden manejar y hay que, si es posible, seguir adelante y si no, bueh, salir de la app...



Despotismo AKA Javier Otaegui
Sabarasa Entertainment - www.sabarasa.com.ar
Creators of "Malvinas 2032"
Seeking publishers

Harvester...

Sounds like you''re talking about Structured Exception Handling.

In C++ though I think exceptions are very useful.
How would you handle something like this?

// prototype
void DrawString(char* str);

// usage - oversimplified...
void DrawString( NULL );

I can see 1 of 3 ways...

1 ) don''t check the pointer

void DrawString(char* str)
{
DRAW_THE_STRING( str );
}

2 ) return early if pointer is null
void DrawString(char* str)
{
if ( str == NULL )
return;

DRAW_THE_STRING( str );
}

3 ) throw an exception

void DrawString(char* str)
{
if ( str == NULL )
throw "str is NULL";

DRAW_THE_STRING( str );
}

Now I suppose which one you choose indicates your error handling philosophy.

1 ) let ''em burn
2 ) cover up for the error
3 ) draw immediate attention to the error condition

Even if you log the error in case 2 you are covering up the error. Maybe this is fine for what you want and it really doesn''t matter. The problem is it makes debugging more difficult because you do not know why no text was displayed.

As far as why no exceptions in MS APIs...

- APIs where there before C++
- must work with other languages
- exception handling implementations are compiler specific

Now as far as DirectX, the last two still apply. Especially since one goal of COM is to be language neutral.

The whole point of exception handling is to make error handling the burden of the component writer. What would happen if you don''t check the error return code of a function ? who knows?

You can''t guarantee that the error return code will be checked, but you can guarantee that throwing an exception WILL change program flow and hence prevent the continuation of a program in an error state.

I agree that you have to be careful about where to use exceptions, and if you make a design decision to not employ them, then fine, you just have to be more careful. However, it is hard to make sure that OTHER people using your code are just as careful.

Also, something to note, that if you are using classes on the stack then you are paying for the cost of destructor cleanup, which seems ( at least from what I can tell ) to be a significant amount of the cost incurred by a try block.

As far as destructors not getting called when leaving a try block or other block via a goto, that is a bug in the compiler. I remember Borland having to fix that exact bug in their compiler.

Well, i decided to use this model in the error handling of my library...

1) Try to recover from errors locally
eg: if (SURFACELOST) then Restore;

2) If the error is not recoverable, log the specifics and end the application in a friendly way (as friendly as i can get it to be, since it''s an error )
eg: if (!Restore(lpLostSurface))
{
Log ("DDError:couldn''t restore surface")
}

Do you think this is enough? (i will try to avoid exceptions for now)