Game Engine questions :)
Author
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.
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...
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...
I am using exceptions in my new C++ game engine because I've truthfully gotten quite tired of magic numbers.
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.
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.
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.
Quote:Original post by RavuyaQuote: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 hereEDIT:
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...
Well, with exceptions the above code would look like this:
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.
amazingCrashyApplication: if connection is broken: throw ConnectionBrokenExceptionamazingNonCrashyFunction: amazingCrashyApplicationamazingNonNonCrashyFunction: amazingNonCrashyFunctionamazingMainFunction: 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.
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.
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
... 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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
