You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
The text was updated successfully, but these errors were encountered: