Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash Report System #33

Open
2 tasks
BenCheung0422 opened this issue Dec 23, 2024 · 0 comments
Open
2 tasks

Crash Report System #33

BenCheung0422 opened this issue Dec 23, 2024 · 0 comments

Comments

@BenCheung0422
Copy link
Member

BenCheung0422 commented Dec 23, 2024

Original: MinicraftPlus/minicraft-plus-revived#461

Background

As the current crash handler uses popups as the crash information, but the popup does not block the all threads from having chances leading to further more errors and crashes. An immediate program exit is the most ideal way to handle a crash, but a report about the crash is important to debug.

Details

Several levels and types of errors should be handled in different methods. It is also expected ALL the errors, problem or exception that might occur and their occurrence chance is not zero at all, should completely be handled whatever a
expected report is generated or further handling is done. Also, Java application styled popups should be replaced by an in-game display with error/exception information. There should not be any unhandled exceptions or errors unless they are completely unhandleable.

  • Fatal Error/Crash - When there is an error, problem or exception that makes the application no longer runs properly or more errors would occur in continuous execution, an exit is required. A crash report file with data dumps (details) is generated.
  • Critical Error/Failure - When there is an error, problem or exception that makes the application behaving unusual or unexpected behaviours, and it might lead further problem, an exit should be done with a crash report with data dumps generated. This includes default application textures problem.
  • Global Error - When there is a global (application-wide) error or exception, but having alternative way to handle it without leading further problems, a notice should be informed. Details should be dumped.
  • Instance Error - When there is an error or exception occurring within any sub-application system or threads, but no further problems would be made in an exit, an exit should be done with a report. This includes errors with a world instance.
  • Exception - When there is an exception or problem having no further problem omitting, and if it is omitted, a log message (or warning) should be logged. Or else it should be having alternative handle and is handled. A log message is recommended.

In addition, design errors will be handled as fatal errors in developer's mode (debugging enabled) and suppressed exceptions in production.

Tasks

Each one following would be converted to a pull request when it is the time, checked when merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment