[Feature Request]: Roll custom exceptions over std::runtime_error

[swagtoy]

Feature Details

Right now a lot of code is burdened with std::runtime_error (std is implied in text from now on, just like what the rest of C++ contracts), which sounds nice in quick issues, but could definitely be improved and will allow for generating cleaner crash reports and MUCH better catching. Even if it's to_string'd at the end of the day, it is generally good practice to roll/extend runtime_error which allows for catching specific errors and handling them as such. Catching all errors is not considered a good practice, nor is runtime_error in the long run.

Also willing to tackle this. Take the tilemap.cpp code which i just so happened to be skimming over, we have throw std::runtime_error("Wrong tilecount count.");, but other than catching in an appropriate manner, how do we know the "category" of the error being caught, and how do we just catch errors with tilemap objects?

Feature Purpose

afasdasd

Concept Screenshots

No response

Guidelines For Reporting Issues

• I have read https://github.com/SuperTux/supertux/blob/master/CONTRIBUTING.md#bug-reports.
• I have verified this isn't a request that's already been submitted as an issue.
• I have verified this isn't a discussion, or an issue with the game, but rather an actual feature request - a currently non-existent, but desired feature.
• In this request, I have only included details about one (1) desired feature.
• If I make a mistake while submitting this request, I agree to use the "Edit" feature to correct it, instead of closing this issue and opening a new one.

[swagtoy]

actually this is a probably a bug report but I dont care really

[tobbi]

I agree that having separate exception types / classes that extend std::exception and then catching those specifically makes a lot more sense than just catching runtime errors, especially because that way we could "swallow" actual errors that are caused by bugs. Feel free to work on it!

[swagtoy]

Yeah. Generally speaking though, something i think i noticed is that you need to use exceptions for what they are. Exceptions. If a function has a chance of not returning a specific type or whatever, it would sometimes just return an exception instead of std::optional or a union/std::variant of some sort.

Especially more so for games, use exceptions very sparesely. Some gamedevs are EXTREMELY strict on Exceptions and have policies to only use them for low-level implementation details. For handling game "errors", this is honestly not how they should be used.