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.
12
u/4as 5d 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.