Sign in to follow this  
chimera007

Game Engine questions :)

Recommended Posts

Hi, thanks for reading the post. Now lets hit it. 1) In a game engine, or my whanna be, how do i implement errors? As error codes returned by functions or Error handling with exceptions with "try...catch". If you have a better idea, i am open. Not that way :P 2) In my engine i use subclassing as a way to keep code tidy. Is that ok? It is my first. EDIT: I mean not subclassing but inheritance with abstract base classes.

Share this post


Link to post
Share on other sites
Hey,

What language are you using? I m building a game engine in C++ and i use ints to catch errors... i have a error.h which defines errors, and SUCCESS is defined as 0. Most of my functions return int and i check this int for success. I got a tiny switch based function that converts an int to a string for debugging or critical error display. This works for me.

As for subclassing, if you just keep it OO i guess it is fine. Keeping your code tidy is definitly the way to go, but don't overdo it.

Greetings...

Share this post


Link to post
Share on other sites
Quote:
Original post by chimera007
1) In a game engine, or my whanna be, how do i implement errors? As error codes returned by functions or Error handling with exceptions with "try...catch". If you have a better idea, i am open. Not that way :P

It depends on the type of the error. You use exceptions for truly exceptional conditions - conditions from which that piece of code is incapable of recovering. You use status return values when, based on the value and internal system knowledge, the code can recover and perhaps do something else.

Another consideration is what errors to display to the user and how to display them. If the software has alternate paths still to attempt, don't show the user anything more than a notification. Showing a message box asking him to just click "OK" is a waste of his time. Only if the program requires user action to continue should you display a prompt.

Quote:
2) In my engine i use subclassing as a way to keep code tidy. Is that ok? It is my first.

EDIT: I mean not subclassing but inheritance with abstract base classes.

Inheritance is not a code organization technique. Look up namespaces.

Share this post


Link to post
Share on other sites
Quote:
Original post by Ravuya
I am using exceptions in my new C++ game engine because I've truthfully gotten quite tired of magic numbers.

You got my interest :)

Are there any pitfalls using numbers? I did use exceptions in my previous projects but using numbers works practically the same, just use an if or switch in stead of consecutive catches.

Share this post


Link to post
Share on other sites
Quote:
Original post by Limitz
Are there any pitfalls using numbers? I did use exceptions in my previous projects but using numbers works practically the same, just use an if or switch in stead of consecutive catches.

It's ugly to read and follow (Washu, I think, has an enormous rant on magic numbers in his journal). Exceptions are explicitly designed for that kind of error condition, and if properly constructed and handled can be very powerful.

You can also centralize your exception handling code several layers deep without having to do logic like:
amazingCrashyApplication:
if connection is broken:
return OHSHIT;

amazingNonCrashyFunction:
if(amazingCrashyApplication returns OHSHIT)
return DOUBLE_OHSHIT;

amazingNonNonCrashyFunction:
if(amazingNonCrashyFunction returns DOUBLE_OHSHIT)
return TRIPLE_OHSHIT;

amazingMainFunction:
if(amazingNonNonCrashyFunction returns TRIPLE_OHSHIT) {
// Quick, fix the error
connection.close();
}
}

Also, what if you have a method that returns std::string but can also throw an exceptional error condition? Do you return an empty string? Do you have to write additional logic for that somewhere down the line?

You're basically coupling your main function to your sub-function if you then have a custom handler (if readLine = "" return OHSHIT), which is generally not such a great idea.

Share this post


Link to post
Share on other sites
Quote:
Original post by Ravuya
Quote:
Original post by Limitz
Are there any pitfalls using numbers? I did use exceptions in my previous projects but using numbers works practically the same, just use an if or switch in stead of consecutive catches.

It's ugly to read and follow (Washu, I think, has an enormous rant on magic numbers in his journal). Exceptions are explicitly designed for that kind of error condition, and if properly constructed and handled can be very powerful.

You can also centralize your exception handling code several layers deep without having to do logic like:
amazingCrashyApplication:
if connection is broken:
return OHSHIT;

amazingNonCrashyFunction:
if(amazingCrashyApplication returns OHSHIT)
return DOUBLE_OHSHIT;

amazingNonNonCrashyFunction:
if(amazingNonCrashyFunction returns DOUBLE_OHSHIT)
return TRIPLE_OHSHIT;

amazingMainFunction:
if(amazingNonNonCrashyFunction returns TRIPLE_OHSHIT) {
// Quick, fix the error
connection.close();
}
}

Also, what if you have a method that returns std::string but can also throw an exceptional error condition? Do you return an empty string? Do you have to write additional logic for that somewhere down the line?

You're basically coupling your main function to your sub-function if you then have a custom handler (if readLine = "" return OHSHIT), which is generally not such a great idea.


Ok, you got a point, however, in my engine i am consitently using an int to return errors and in the case of a function that needs to return a string i would pass it as a pointer into the funtion. The advantage here is that the calling method is more readable in my opinion.

example:


char result[80];
int error = getSomeString(result);
if (error) return error; // handle it at the top or take action

//handle the string here


EDIT:
as for the consecutive error passing: I would handle the error where it is appropiate, dont throw everything to toplevel, and i can return errors as i go in a function. If i have an error that needs passing to toplevel, i would just return that error code. Don't create different error codes in every function the error passes through...

Share this post


Link to post
Share on other sites
Well, with exceptions the above code would look like this:
amazingCrashyApplication:
if connection is broken:
throw ConnectionBrokenException

amazingNonCrashyFunction:
amazingCrashyApplication

amazingNonNonCrashyFunction:
amazingNonCrashyFunction

amazingMainFunction:
try {
amazingNonNonCrashyFunction
catch(ConnectionBrokenException) {
// Quick, fix the error
connection.close();
}
}

So, really, it is still quite clean, but you can do a lot of very interesting things with exceptions.

Whether you go with magic numbers or exceptions it's important to know the pros and cons of both, and make a measured decision. With magic numbers, you can't easily implement a stack trace, unlike with modern exceptions (perhaps with an error string or specialized type of error object, you could approximate this behaviour).

I think it's a more modern, and much cleaner, way of managing deferred error handling, particularly if you have many calls in one method which may throw many different types of error.

Share this post


Link to post
Share on other sites
Quote:
Original post by Ravuya
With magic numbers, you can't easily implement a stack trace, unlike with modern exceptions (perhaps with an error string or specialized type of error object, you could approximate this behaviour).

Note that I am not disagreeing with you in any way, but you should also note that this is also a key reason that many people don't use exceptions. The overhead used in exceptions for the stack trace, etc.

Share this post


Link to post
Share on other sites
Generally, exceptions are better when an error occurs that stops the ordinary processing from continuing. An example of that is if you can't find the level file you're trying to load, or if your D3D device is invalid. They will 'get you out of there' and back to a known safe point where you can clean up and try again.

In contrast, a status return code is for situations where you might want to change how subsequent processing is done, but it can still carry on. For example, if you determine the game is running too slowly, you might draw less detail in the next frames; if your log file won't open, you might log to a console instead.

I tend to feel code that goes
   if(RETURN_ERROR == someFunction()) return;

... or similar is a bad idea – that should be handled by exceptions.

Also, in C++ you shouldn't use ints for status codes, you should define an enum of result codes.

Share this post


Link to post
Share on other sites
That looks very neat, however, one of the main problem i run in to with try catch constructions is that when you instanciate variables in the try clause you cant use them in the catch portion. I did a huge project once with try catch and it just didn't do it for me :)

As for Chimera: I think if you start from scratch you may go with the try catch method, it is more modern and has more capabilities, but its just not for me :)

Greetings...

EDIT: previous post -> use enums ... i guess i'm still a C fanatic maybe, i like to stay as low level as possible. Compiler wise it isn't that big of a difference anyway, enums or ints.

Share this post


Link to post
Share on other sites
Quote:
Original post by Saruman
Note that I am not disagreeing with you in any way, but you should also note that this is also a key reason that many people don't use exceptions. The overhead used in exceptions for the stack trace, etc.

I would imagine that in an exceptional circumstance you don't care much about the overhead. [wink] I generally use exceptions in the same area as 'error returned' places in my game code; e.g. some NPC is trying to reference a NULL object and so I must catch this and reassign its target rather than just returning a magic number for NPC_TARGETED_NULL.

But yes, you do have a good point there. However, my game engine is GPU bound.

Share this post


Link to post
Share on other sites
I have read all of the above posts and seem that i am going for try catch, if you haven't noticed i am working with C++, noob :p.

What i was thinking of implementing was a exception class, for example:

//Errory code here
throw CMyExeption(LINE, FILE, ERROR(d3d hr or something by that maner));

With that i think i can implement only one or to exception classes, probably one solely for D3D, and a Generic one. In that class what i do is write to a "error.log" with something that looks like this:
<X> Error in file: "holyPoop.cpp", line: "2323", D3D error code 32423432: "Unable to load texture blabla.img"
<!> App closing due to major wierd error.

I am not very fond to error managing, i just like to skip it all, its to much work at 3 am whne tring to write as much as posible before 4 am :P.

EDIT::: When i throw and exception, do i go back to executing in the same function?
Say i have this:
{
LoadTextureCodeHere;
if OMFG Failed(hrD3D)
{
throw CExep(OWNED!);
FixError here?
}
ContinueFunctioning;
}

In my head exceptions are only there to let you know about it, but you should be able to fix it rgiht there. Right? If not woop my nooby ass with the 6Million answer :). Sorry i am being so childish, i thought that if all say badwords i can too.

[Edited by - chimera007 on July 19, 2006 1:13:46 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Ravuya
I would imagine that in an exceptional circumstance you don't care much about the overhead. [wink]

I agree but there is overhead just for having a single try/catch in the application and having exception handling turned on. Although note I only posted for clarity and I am not promoting the use of error codes vs exceptions or anything.

Quote:

But yes, you do have a good point there. However, my game engine is GPU bound.

True pretty much any engine will be, but once there is a game using it will it still be? :) Again though don't think I'm saying not to use exceptions or optimizing early or anything like that... just wanted to point that out.

Share this post


Link to post
Share on other sites
Quote:
Original post by Saruman
True pretty much any engine will be, but once there is a game using it will it still be? :) Again though don't think I'm saying not to use exceptions or optimizing early or anything like that... just wanted to point that out.

Mm, the aforementioned game is the one in my journal. And yes, it is GPU bound. Although since I upgraded this may no longer be the case.

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