Error Handling
Author
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.
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.
I normally use return values, but I use exceptions in constructors and memory allocation.
Author
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.
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.
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.
I like exceptions myself, but writing truly exception-safe code is something you have to train yourself to do. I am still learning it.
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
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
Author
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.
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.
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.
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: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.
// with exceptionsvoid prepare_level(){ load_textures(); load_models(); load_level();}// with return codesERRCODE 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;}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.
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
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
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]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
