Jump to content



Exception Handling and Fatal Errors

  • You cannot reply to this topic
9 replies to this topic

#1 ILoveJesus   Members   -  Reputation: 103

Like
0Likes
Like

Posted 19 February 2012 - 03:11 PM

I am working on my first serious 2D platformer for PC with Directx11, and Microsoft Visual C++. I have some exception handling done but not all. I have nothing yet for fatal errors. For example when loading resources I don't check to see if the resource is there, so if the file is renamed, moved or deleted the program probably will crash. Now I decided to simply use my own system to handle this. I'll check to see if the file is there before it is loaded and if it isn't I'll call a function that shows a messagebox with the error code and explanation of what caused it and any button will shut down the program. Now is this ok? I don't see how I could recover the program with a necessary missing file. Unless I had a backup folder with all necessary resources and moved the missing file back to where it is missing? Why go through all of that if the player shouldn't be tampering with such files anyway correct?


Also a general question regarding exception handling. Let's say a integer needs to be between 1 and 10 for the program to function properly. Now if I am sure that the program is set up in a way to where this integer won't have a value outside of its boundaries is an exception check even neccessary? Is it possible for a freak thing to happen and the variable wind up having a wrong value for some reason outside of the program's control?

Ad:

#2 Washu   Senior Moderators   -  Reputation: 2448

Like
0Likes
Like

Posted 19 February 2012 - 03:14 PM

A missing texture? Use your debug placeholder. A missing model? Use a debug placeholder.

Common examples of this is that many games have a magenta texture or the like which appears nowhere except where textures are missing. For the model its often a large cube or similar object that will never appear in game. Again, its just a placeholder.

These are common fallbacks, which you will need during development at the least, while you get art assets sorted out.

Only when you have no other recourse should you CtD.
In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.
ScapeCode - Blog | SlimDX

#3 ILoveJesus   Members   -  Reputation: 103

Like
0Likes
Like

Posted 19 February 2012 - 03:19 PM

Wow that is actually a good idea for textures. Nonetheless though, the player would be inclined to reinstall or repair whether the game crashes or if it continues with single color textures right? What I am asking I guess is do I have to have the program recover from a missing texture?

#4 Washu   Senior Moderators   -  Reputation: 2448

Like
0Likes
Like

Posted 19 February 2012 - 03:22 PM

Yes, you SHOULD program to recover from a missing texture, you could report the error to the player at the least, and at best you could download a patch online to fix the issue.

"Warning: Data files necessary for running this game are unavailable. Should an attempt be made to repair the game?" [Y/N]
In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.
ScapeCode - Blog | SlimDX

#5 ILoveJesus   Members   -  Reputation: 103

Like
0Likes
Like

Posted 19 February 2012 - 03:23 PM

Ok thank you.

What about my second question though in my OP.

#6 SiCrane   Moderators   -  Reputation: 2378

Like
0Likes
Like

Posted 19 February 2012 - 04:07 PM

Yes, it's possible for numbers to change at random. It can happen when dealing with hardware failure/overclocked processors and it can also happen if someone is trying to cheat at your game and is rewriting memory. It can also happen if you make a mistake and dereference a bad pointer or overrun a buffer.

#7 ILoveJesus   Members   -  Reputation: 103

Like
0Likes
Like

Posted 19 February 2012 - 04:29 PM

So I have to do exception handling for pretty much everything? Fun fun fun.

#8 rip-off   Moderators   -  Reputation: 2482

Like
1Likes
Like

Posted 19 February 2012 - 05:47 PM

For your second question, if something very unexpected occurs, like SiCrane's list, then you pretty much cannot depend on anything. If you expect the value is valid, then use an assertion for Debug mode, and cross your fingers in the shipping code. Don't use exceptions for things that should not occur. Exceptions are for possible but improbable situations, not for "impossible"(assertion in Debug, all bets are off in Release) or probable situations (error codes or fallback behaviour).

#9 ILoveJesus   Members   -  Reputation: 103

Like
0Likes
Like

Posted 19 February 2012 - 06:07 PM

Makes sense. I mean a good example is what I am doing right now. I am using my own textures for the font and box for my errorbox. Now I simply load my errorbox texture file and font texture atlas anytime an error box needs to appear. All of a sudden I thought ok, well what happens if those two texture files are not there or the other two files that are needed to load this particular font properly? Do I do an exception check inside my error code and call it again with a different font and textbox if those other two aren't there? Lol. i was driving myself crazy. If I do this my way then I have to hope no one ever tampers with those specific files.

#10 colinhect   Members   -  Reputation: 187

Like
0Likes
Like

Posted 21 February 2012 - 02:57 PM

Based on your last post it sounds like you might be loading resources manually as different parts of your code needs them. I would recommend you look into writing a centralized resource cache to abstract away the IO details (and error handling).

Here is an example of how mine works:


ResourceCache resourceCache("Data.zip");
shared_ptr<mesh> someMesh = resourceCache.get<mesh>("Test.mesh");
shared_ptr<mesh> someMeshAgain = resourceCache.get<mesh>("Test.mesh"); // The mesh is not loaded again.  A pointer to the cached mesh is returned.
shared_ptr<textuer> someTexture = resourceCache.get<texture>("DoesNotExist.png"); // The texture does not exist.  A pointer to the default texture is returned.


Notice how no exception handling is needed when retrieving resources. And with the raw IO abstracted away the code doesn't care if the files are on the filesystem, in a zip file, over a network, etc...

Since the IO is abstract you can also have resources existing in different sources. For example, you can have core resources built with the executable so that they will not fail to load unless someone messes with the executable.






We are working on generating results for this topic
PARTNERS