   Should I <i>try</i>?
  When designing my game, I made this CApplication class which is actually the place where my code gets executed. Anyway my main() looks like this   int APIENTRY WinMain(HINSTANCE hInst, HINSTANCE, LPCTR, int) {CApplication app;if (FAILED(app.Create(hInst)))return –1;return app.Run();}Will folowing change have any performance hits.   int APIENTRY WinMain(HINSTANCE hInst, HINSTANCE, LPCTR, int) {CApplication app;try {app.Create(hInst);app.Run();}catch () {}return 0;}
  Why would you bother?   How appropriate. You fight like a cow. ;  does any of those methods throw an exception? if not the try and catch statement are useless... ;  Offcourse they do. I figured out that it is more simple to just throw exception than write if(FAILED)return E_FAIL in every function and every subfunction. I just want to go back instantly. But I am concerned about whether or not try-catch block are slowing down program. ;quote:Original post by ffx  I just want to go back instantly. But I am concerned about whether or not try-catch block are slowing down program.   Not really, unless an exception is actually thrown.In which case, you probably won''t care much.   [ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | C++ FAQ Lite | Function Ptrs | CppTips Archive ][ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Free C++ IDE | Boost C++ Lib | MSVC6 Lib Fixes ] ;  Adding try/catch as you showed will not hurt performance. If an exception is thrown you will get some penalty, otherwise it''s really cheap.You should however not design your applications so that execptions are thrown frequently, as that likely could hurt performance.Exceptions are things that happens rarely, such as "socket connection lost", "out of disk space" etc. A function that tells if a string contains vowels or not "HasVowels()" should typically not throw execptions.That said, you should learn more about exception handling before adding exception handlers as you suggested. Ask yourself: What does it help to catch the exception and hide it? It won''t help the user as the program will just disappear and she doesn''t understand why. Neither will it help you as a developer as you will not know whether it was a bug or an valid exception that was the cause.When catching exceptions, you should catch the exceptions that you can expect and will deal with. If you catch exceptions and hide them, that should really be a conscious decision (or you will likely hide bugs and make them hard to find). Thus it''s generally not good to "catch (...)".I don''t have a simple way of telling you what to do. You should design an application to be aware of exceptions that might be thrown. It''s not trivial to introduce exception handling in old existing code.I''m not the person who can teach you everything about execptions in 5 minutes, but I want to make you aware that it''s a quite difficult thing to do "right". If it is some help, I can tell that I see many people''s code every day, and few of them - even bright people - are good at writing code designed with exception handling in mind.You should really buy a book that deals with exceptions, such as Meyers'' "Effective C++" or Sutter''s "Exceptional C++". ;  hmm, not sure if the c++ standard guarantees that try blocks will cost you nothing, but most compilers shouldn''t let it slow you down.Besides that, WinMain() is only called once in a program''s life. why the hell would you care even if a try block cost you a whole second? ;  Actually, I do know a lot of of exception handling, just I didn''t know are there any slowdowns. Now I know that there aren''t. Exceptions are thrown when there is a critical error. If my new returns NULL, I''ll try to free some mmeemory by calling my memory manager or try something else, or switch methods.I wanted to switch to exceptions because exit() and abort() don''t look so good and I wanted to stop execution without messing with function returns(they become boring).I would like to use SEH, actually (because my game will not be multi-platform). 