Jump to content
  • Advertisement
Sign in to follow this  
TroneX

Error Handling

This topic is 4957 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi folks, what kind of error handling do you use in your code? Starting a little hobby-project on my own (actually a port of an old-style 2D game with a hand full of enhancements ;-)), I have to decide what kind of error handling I would like to implement. Until now, I stumbled over different solutions: - Exception Handling through standard C++ try-throw-catch - Simple asserts (which might not be best in release mode ;-)) - An own error handling class - Direct approach via return codes and global code-2-message What do you guys prefer? Regards, T.

Share this post


Link to post
Share on other sites
Advertisement
I don't consider assert to be error handling because it is normally only enabled during testing. And even then it doesn't really "handle" the error -- it just halts with a message.

I normally use return values, but I use exceptions in constructors and memory allocation.

Share this post


Link to post
Share on other sites
That makes sense, since c'tors don't have return values and exceptions are the only option to handle error occurring there as well. ;-)

Using return values in other cases: My companies last game was based on DirectX and so we made heavy use of HRESULT and all of the nice DirectX error codes (including their error-resolution helper functions. Do you have your own way of doing this, or do you think this kind of handling is oversized?

Regards,
T.

Share this post


Link to post
Share on other sites
The only reason DX uses HRESULTS is cause it is based on COM.

I like exceptions myself, but writing truly exception-safe code is something you have to train yourself to do. I am still learning it.

Share this post


Link to post
Share on other sites
I wouldn't say that's the only reason they use HRESULTS. They actually area good method for returning a multitude of error messages.

And even better there is allready a bunch of them created and an api for dealing with them and reading out what the error's are.

It doesn't hurt that DX is COM based, but, I'd say its more reference counted than COM based now anyway.

Cheers
Chris

Share this post


Link to post
Share on other sites
What I am trying out now is a class for handling a status of a call. I am deriving my classes from this one and so I am able to loop through the returned status code to whereever I want to handle it. This seems to be a nice mixture of exception handling and simple return codes. ;-)

The idea is based on what I learned from Sam Lantinga who used a quite similar approach when developing for Loki Entertainment.

I'll see whether this works okay for me, hehe.

The biggest problem for me at the moment is, that there are dozens of incredible and absolute cool "technologies" out there waiting to be implemented, like STL, smart pointers, FSMs, entity factories, resource manager, template driven algorithms, functors, etc, pp ...

I've got the Game Programming Gems volume 1 to 3 and they are full of great ideas. My little game simply doesn't need such overhead in most cases, ... but I'd love to try 'em all out ;-))))

Maybe that's because my last project didn't allow me much to try out and experiment with such techniques or modern coding styles, hehe.

T.

Share this post


Link to post
Share on other sites
Asserts are really for enforcing design-by-contract and otherwise making sure that functions behave like they were meant to. C-style asserts are bad because they don't let a program clean up after itself (no destructors are called). That's why C++ has the std::logic_error exception class.

Share this post


Link to post
Share on other sites
Exceptions are typically much easier than return codes. Let's look at a basic function that cannot cause errors in itself, but calls several other functions that can fail:
// with exceptions
void prepare_level()
{
load_textures();
load_models();
load_level();
}

// with return codes
ERRCODE prepare_level()
{
ERRCODE temp = load_textures();
if (failed(temp)) return temp;
temp = load_models();
if (failed(temp)) return temp;
temp = load_level();
if (failed(temp)) return temp;
return SUCCESS;
}
Which would you rather write? Which would you rather maintain?

I'm sure there are some rare cases where exceptions are not feasible for some reason or another. The rest of the time, they're too useful to ignore.

Share this post


Link to post
Share on other sites
i dont know what it is with the code beer hunter, but from my first look its very unstable, and prone to errors itsself....

i can be totally wrong about it, but changing temp to an error code seems a bit.... dangerous. what for example if you have multi-errors? then the error code shows only the last error. it can be me, but i guess u need a break inside the code

Share this post


Link to post
Share on other sites
If an operation can cause multiple errors, then, sure, you can't get all the information from return codes. You could probably return an object that represents all the errors that have occurred, but at that point, I'd rather just throw it. [smile]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!