Sign in to follow this  
TroneX

Error Handling

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
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
Hm, ... throwing errors, ... do you create custom exception objects for this and if so, how do they look like?

Do you always catch these error where the throwing function has been called or somewhere else? Or do you handle this centrally?

I would be glad, if someone could give me a little sample... ;-)

T.

Share this post


Link to post
Share on other sites
Quote:
Do you always catch these error where the throwing function has been called or somewhere else? Or do you handle this centrally?
Only catch exceptions that are expected, and only catch exceptions where it makes sense to recover from them (unless you rethrow the exception).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this