using gotos? *shrugs* id rather die! how about:

try
{
int* a = new int[100];
...
}
catch(...)
{
// exception caught, free memory
delete[] a;
}
...

and as the logging part goes i myself just overload the clog stream with an ofstream (ofstream logfile; log.open("abc.log"); clog = logfile; ) and then i simply output text and whatever to the log using:

clog << "exception caught: " << error << whatever << endl;

iostream takes care of all the formatting stuff for you, yay. no need to call sprintf or such like anymore.

Edited by - Staffan on 2/15/00 12:24:10 PM

Staffan,

I can appreciate try catch throw methods, but, for personal tastes, I find they take up too much room.. maybe its my familiarity with vic 20 basic. Anyways..

Well, then i guess the following would be bad news.
The next generation of Visual Basic will support Try, Catch, Finally exceptions handling!

http://msdn.microsoft.com/vstudio/nextgen/language.asp


As for gotos, misuse is bad, and it is frowned upon when misused. But many people have taken goto as taboo. Sure, you can rewrite it without goto, but that does not mean you can''t use goto. If you say goto is bad and taboo, and kept mentioning why it is bad, it *might* mean
- you can''t code readable codes. This is the duty of the programmer, don''t blame the language itself
- you can''t think of a better way than goto, wants to use it, but afraid of being flamed

To Sphet: I''m supporting you all the way, though I have a couple of tricks up my sleeves that would be better than gotos

I''d always thought the major problem with goto''s and C++ is that the destructors for objects allocated on the local stack are NOT called when you jump. That, of course, can cause memory leaks, and all other kinds of bad.

Here''s my take on errors. Errors are unrecoverable programatic mistakes, like a GPF. Exceptions are just deviations from the normal flow of coding. Personally I think returning error codes is bad design, unless the function is desinged to fail 50% of the time. Exceptions would be the way to go if I were you. Exceptions are just that, they are exceptions to the way your code is supposed to flow. Try blocks are pretty expensive in terms of cpu time, but so are many unnecessary if statements.

Daniel:

I think that you misunderstood my log() function.

I use it primarily for debugging, finding those errors that should never happen. These are the important ones, the other errors aren''t even errors, they are just things that can happen (for ex. trying to read a file that doesn''t exists). You must prepare well your functions to deal with this problem, to recover, and if you couldn''t solve it, well, the app must be able to continue without moaning. If an app-critical error outcomes, well, then you will have to terminate the app, and you should quit from the point you discovered it was critical. Log() cames later for proper debugging. Of course you can settle logs everywhere, and when something occurs, you find it at once, I do this a lot.

There is a simple rule. Your application must deal with common errors. You can''t deal with everything. You can''t deal with a martian attack from your code. I''ve used the log() tecnique in a game I have finished, and I can proudly say that it''s incredibly stable, and no bugs have been yet found since the commercial release of the game (2 months ago).

By the other way, this: DDraw(DDERR_INVALIDPARAMS)<-Sprite(SPRITEERR_DDRAWFAILED)<-Tileset(TILESETERR_SPRITEFAILED) que pones en el primer mensaje es una burrada. Como Ddraw->Sprite es un objeto y Tileset es un metodo (supongo), lo unico que retorna error ahi es Tileset... Creo que te estas armando un lio con c++ al reverendisimo cuete.....


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

Javier,

I understood your Log system. You use them to track critical errors, for debugging. That is pretty clear. I also understand that my app should deal with recoverable errors (like "file does not exists")

Pero no entiendo tu planteo...
Es un esquema con 3 objetos...
Una superficie, un tile y un tileset. El main trabaja con el tileset. El tileset maneja los tiles, y cada tile tiene una referencia a una superficie, y se encarga de dibujarse.
Si la superficie no puede copiarse por alguna razon, el tile arroja un error de que no puede copiarse, el tileset se encuentra con que no puede copiar un tile, asi que informa al main que no pudo hacer el renderizado exitosamente.
El diseño que hice funciona de esa manera...funcionar funciona, el tema es si el la manera mas comoda...alguna idea?
Me gusto el termino "burrada"

Daniel.

By any mean... Exceptions are greate (the only way to catch CPU errors), but for god''s sake, you can''t just use ''em anywhere...

Exceptions are STRICTLY used for CPU errors. Like i said, we can manually produce an Exception, but hell... it SUX...

I''ll never RAISE an exception for software error detection. Although windows provide strong foundations for Exceptions, everthing can be as easily implemented.

PS: Software Exceptions are also used in DLLs, when there''s no error reporting design.

PS: Why do you think MS doesn''t use Exceptions for error trapping in their dlls???? Instead they use the GetLastError() function....

However, these are tastes.
Again i prefer return codes.

PS: In the matter of speed... cmp, test, etc... are hellable faster... i don''t think you can change the value of the Exception flag the CPU. Yet, if that was possible, with all the Windows load behind it.... it SUX.


Paris Theofanidis
X-treme DevTeam
( http://www.x-treme.gr/ )

quote: Original post by Harvester

PS: Why do you think MS doesn''t use Exceptions for error trapping in their dlls???? Instead they use the GetLastError() function....

Are you refering to the Win32 API, or MFC? If you are refering to the Win32 API, then the reason why they don''t use exceptions is simple - Not all languages support catching exceptions.

It''s not because it''s slow. It''s not because it''s not a good way to handle errors. It''s because they wanted to use the same API functions (more or less) under any given programming language available for their platform.

Josh

Whoops! That last post was mine. Seems I forgot to enter my username and password

Josh