Improving error handling of expected errors

[Brutus5000]

Is your feature request related to a problem? Please describe.
It creeps me out that we throw away expected exceptions and turn them into runtime exceptions showing them to the user in a "Uh oh, something went wrong we have no clue what" even if we exactly know what the problem was.

This is sort of the result of the relentless suppressing of checked exceptions all over the code.

Unfortunately our users are not capable of reading a stack trace and understanding it. We should try to wrap it into more useful error logs.

Examples:

• If there is a runtime exception related to the game process and an IO exception is flying we know the game has crashed. And we could catch this properly and point the the user to basic game fixes (e.g. turn of your mods, surround sound, ...)
• If on preparing the game to launch we encounter a AccessDeniedException we can tell the user that there was some issues with setting up the files and potential solutions (Check if game already running, restart pc, try to fix Windows permissions, deactive AV)
• LoginFailedException: Lost connection to server during login -> it already is a wrapped exception and just needs a nicer text
• ...

In cases were we do not catch the exception we could at least try to unwrap CompletionExceptions and remove one layer of exceptions to bring the user closer to the root cause.

[Sheikah45]

Yes I agree have been slowly trying to move towards this.

For tracking:

With the loginFailed Exception those should actually be fixed by the lobby client now might need additionaly wrapping but have not seen what these errors are recently.

There is a wrapping process for the game crashing currently based off the exit code of the game log. We could add additional scanning of the game log to identify specific known issues.

AccessDeniedExceptions can give direct response of which files could not be accessed

[Sheikah45]

This should probably start by removing the noCatch and sneakyThrows

[micheljung]

I have to intervene here.

that we throw away expected exceptions and turn them into runtime exceptions
This is not true. Expected exceptions are not "thrown away", they are wrapped because that's the only way (except the @SneakyThrows hack) to not have to declare exceptions. Checked exceptions are very controversial but look at Kotlin which got rid of them and the world - including me - is absolutely in favor of it.

the result of the relentless suppressing of checked exceptions all over the code
Again, checked exceptions are not suppressed. They are merely wrapped.

It is true that wrapping them in a plain RuntimeException is lazy and not the best error handling. What needs to be done is distinguishing between technical exceptions (Like IndexOutOfBounds, NPE and such) and business. Per your examples:

• Throw a GameCrashedException
• Throw a GameLaunchFailedException
• Improve LoginFailedException

All these exceptions will extend RuntimeException or if you want, something like BusinessException (feel free to find a better name than "Business"). These exceptions can then have a getI18nKey() and getI18nArgs(), for instance, in order to render a decent error message to the user.

Not throwing exceptions at all and just silently logging them or, even worse, returning empty or null values, like done in #2373 is not the solution to this problem.

[micheljung]

I see that brutus clarified in #2368 what he meant and we seem to agree.