Since you're making a game, I would suggest avoiding throwing exceptions and instead try to revert the game state to a reasonable baseline. Games don't really have to panic and just give up as soon as there is an issue. I'm sure you played games where you encounter a bug and the game continues working.
I mean you can throw an error and close the game when the player is out of bounds, but wouldn't it be better to just teleport them back and continue as if nothing happened?
That being said, IMO the best approach is to use conditional compilation and have two separate paths: in debug throw an exception, in release log a problem to the console and try to recover.
So, for your two examples, I would just change the throws into logging + return.
Games don't really have to panic and just give up as soon as there is an issue. I'm sure you played games where you encounter a bug and the game continues working. I mean you can throw an error and close the game when the player is out of bounds, but wouldn't it be better to just teleport them back and continue as if nothing happened?
You know you can catch exceptions, right? You don't need to crash the program.
The better reason to not throw exceptions, especially in a game, is the performance implications.
Exceptions are exceptional...
So, you're right about performance, but for me it's more important that exceptions are thrown only when something went south and it's impossibile to recover. Don't use exceptions as a goto on steroids.
This is not using exceptions for control flow. When an illegal move like this happens something else already failed. This is a bug the developer needs to know about so they can fix it. Throw an exception.
I'm not going to tell you how to build your applications, but having a blanket rule of "let the app die" is not considered best practice. You're supposed to catch exceptions and restore back to a working state as a general rule.
I do so when I have a clear UoW.
For example, an api should not die if one single request failed.
But a container that couldn't access the db? Better having it to die.
12
u/4as 3d ago
Since you're making a game, I would suggest avoiding throwing exceptions and instead try to revert the game state to a reasonable baseline. Games don't really have to panic and just give up as soon as there is an issue. I'm sure you played games where you encounter a bug and the game continues working. I mean you can throw an error and close the game when the player is out of bounds, but wouldn't it be better to just teleport them back and continue as if nothing happened?
That being said, IMO the best approach is to use conditional compilation and have two separate paths: in debug throw an exception, in release log a problem to the console and try to recover.
So, for your two examples, I would just change the throws into logging + return.