   Best method to catch errors
  HiI have a function I am writting in C++ & I need to catch when a function fails. So I have my code but its really bad in how it checks for errors, just ALOT of if statements.Can you suggest better ways to check when a function fails: Would one of these be better: - try catch - assert() - FAILURE(SetBkMode(..)); - raise?If its any of the above, would you be able to provide an example especially with try catch. Also, I think I remember reading its bad to use try catch in c++ for some reason, is it true I should avoid try & catch statements in c++?Note, I want to identify when a function fails BUT not close the program(like assert does) just return false.    bool foo(){// I am trying to find an efficient way to catch any errors in the following code.    // The below looks like, I think they call it 'spagetti coding'? Well its really    // bad code   int success;   success = FillRgn(hdc,region,bgBrush);   if (success == 0) {   return false;    }   success = FrameRgn(hdc,region,frameBrush,1,1);    if (success == 0) {   return false;    }   success = SetBkMode(hdc,TRANSPARENT);    if (success == 0) {   return false;    }    success = SetTextColor(hdc,textColour);    if (success == 0) {   return false;    }   success = TextOut(hdc,textPos.x,textPos.y,data.c_str(),data.length());    if (success == 0) {   return false;    }   return true;  }
  Returning error codes is the C way of handling errors.In C++ you use exceptions. Writing exception safe code isn't easy.   ;  Well i dont think its spagetti coding, ive only seen that term refer to code that used gotos to fly all around the place in confusing ways - but maybe there's other kinds of spagetti code too :PAnyhow, some options for you (:...   if((success = FillRgn(hdc,region,bgBrush))==0)return false;   if((success = FrameRgn(hdc,region,frameBrush,1,1)==0)return false;...But you can actually simplify that to......    if(!FillRgn(hdc,region,bgBrush)) return false;    if(!FrameRgn(hdc,region,frameBrush,1,1)) return false;...That above is pretty clean.  If you wanted to go even further you could do something like this though...    #define VERIFYSUCCESS(x) if(!x) return false;    VERIFYSUCCESS(FillRgn(hdc,region,bgBrush));    VERIFYSUCCESS(FrameRgn(hdc,region,frameBrush,1,1));...Do you see anything you like better than the way you are doing it? (:And hey for the record!Working at 3 different c++ console game development companies, and 10 years total C++ professional programming experience, I have yet to see anyone use exceptions.We use asserts all the time, but we return and check for errors from functions.If you think thats awful, middleware works the same way... havok, fmod, and all the libraries that are supplied by a console company to let you program your game, none of them use exceptions.  They all just have functions that return errors.The only time i have ever seen people use exceptions in C++ was in school :Plpcstr brings up a good point, that it's difficult to program exceptions correctly.  I think that right there is the reason that they aren't used.  The more complex something is, or the harder it is to get right, the more likely you are to screw it up, so the more people will avoid using it since we all want to make bug free code with minimal effort (and cost).Tossin my experiences in the bucket to help guide ya (:[Edited by - Atrix256 on May 14, 2010 11:01:17 PM];  Thanks for the advice :D@Atrix256 Your examples are really helpful. That last one is cool I think I am gonna use thatThanks again :)   ;  The thing about calling several API functions that only return error codes rather than throwing exceptions is that the easiest way to deal with failures is to wrap the calls in something.You can certainly wrap them in a macro, and later on if you wished to use exceptions then it is a matter of changing the macro to throw instead of return, and potentially turn it into a function rather than a macro.   ;Quote:Original post by Atrix256Working at 3 different c++ console game development companies, and 10 years total C++ professional programming experience, I have yet to see anyone use exceptions.We use asserts all the time, but we return and check for errors from functions.If you think thats awful, middleware works the same way... havok, fmod, and all the libraries that are supplied by a console company to let you program your game, none of them use exceptions.  They all just have functions that return errors.The only time i have ever seen people use exceptions in C++ was in school :Plpcstr brings up a good point, that it's difficult to program exceptions correctly.  I think that right there is the reason that they aren't used.  The more complex something is, or the harder it is to get right, the more likely you are to screw it up, so the more people will avoid using it since we all want to make bug free code with minimal effort (and cost).Tossin my experiences in the bucket to help guide ya (:I also have 10 or more years of professional C++ game development experience including consoles and I also have never seen exceptions used in a gaming environment.  I write commercial middleware, and as pointed out I do not use exceptions in my engine.  The only time I saw exceptions was when I worked at Morgan Stanley.  Financial coding and servers find it more important to simply stay running no matter what chaos is happening inside.The reasons exceptions are not used in game development are:#1: Exceptions incur overhead.#2: Exceptions provide a lazy way out of catching and handling all possible errors, which is unacceptable in game development.  An exception handler may end up catching bugs you did not know were there (and did not intend to catch), and never will because of it.#3: A game engine must be stable because it was coded correctly, not because it has a safety net.  In theory, if the engine is working properly, it will never need exception handlers.There are, however, some cases where exceptions are required.  Exceptions are the only way to error out of constructors and overloaded operators.  The loading of data files should be guarded by exceptions.  Corrupt files can cause unnecessary havoc; they can crash your game entirely when the only thing that was actually necessary was for an error to be printed and false returned.My advice would be to avoid exceptions unless you have no choice.  If your code is correct you do not need exceptions.  Return error codes and assert() properly (for example, using assert() to check that an allocation was successful is not proper).Then, whatever system you put in place, do not ignore it.  It is very tempting when you are under the gun to skip a safety check because the allocation should never fail or such should never happen.It can all happen, and your protections only work if you utilize them.  Check every single allocation, handle every possible failure condition.L. Spiro   ;Quote:Original post by YogurtEmperorMy advice would be to avoid exceptions unless you have no choice.  If your code is correct you do not need exceptions.  Return error codes and assert() properly (for example, using assert() to check that an allocation was successful is not proper). Then, whatever system you put in place, do not ignore it.  It is very tempting when you are under the gun to skip a safety check because the allocation should never fail or such should never happen.It can all happen, and your protections only work if you utilize them.  Check every single allocation, handle every possible failure condition.L. SpiroThanks for the advice :)But how should I error check when I want to check if an allocation was successful?By your last line, do you think that my continual error checking at each line(in my function in the OP) is what I should always do, or is it overkill?   ;  The message loop functions in the WinAPI automatically catch all exceptions, so if you're using them in your code and an exception is raised that you don't catch, you won't be informed about it. This has the potential to make debugging a nightmare.   ;Quote:Original post by YogurtEmperor #2: Exceptions provide a lazy way out of catching and handling all possible errors, which is unacceptable in game development.  An exception handler may end up catching bugs you did not know were there (and did not intend to catch), and never will because of it.That doesn't really hold any water. It may be easy to write a catch(...) block, but it's even easier to just ignore the return values of functions. A certain amount of discipline will be required either way.Quote:#3: A game engine must be stable because it was coded correctly, not because it has a safety net.  In theory, if the engine is working properly, it will never need exception handlers.What kind of theory is that? If exceptions are the standard way of handling errors in a given engine, and they're handled propertly, how does that imply it's not working properly? If forget the exact name of the fallacy, but you're ruling out exceptions as a valid error mechanism (as if a safety net was a bad thing), and then using your assumption to argue that they're a bad idea.;Quote:Original post by YogurtEmperor#3: A game engine must be stable because it was coded correctly, not because it has a safety net.  In theory, if the engine is working properly, it will never need exception handlers.You totally misunderstood what a C++ exception is.Using a C++ exception as a glorified assert is blatantly abusing it. It is not a way to catch bugs. It is a way to handle exceptional circumstances that can arise during normal operation and that are beyond the control of your code. A hardware IO failure during an IO write operation, for example. A memory allocation that failed due to insufficient resources. A vital system file that is not accessible. All these things are exceptional, but they are not bugs. They are rare, but they need to be handled. And C++ exceptions are a very good way to do this elegantly.Then again, exception do indeed have some overhead when they're thrown. They should therefore not be used as a general replacement for status return codes.