Jump to content
  • Advertisement
Sign in to follow this  
chimera007

Game Engine questions :)

This topic is 4444 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, 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
Advertisement
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
I am using exceptions in my new C++ game engine because I've truthfully gotten quite tired of magic numbers.

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
Sign in to follow this  

  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!