Optimize System.exit Usage

[halibobo1205]

Background

There are several cases where System.exit is directly invoked to terminate the system after encountering specific exceptions. While this approach is straightforward, it can lead to various technical debts:

1. Poor maintainability: Scattered System.exit calls make it difficult to trace and maintain program workflows.
2. Testing Environment Impact: Code containing System.exit is challenging to unit test. Such calls cause Gradle unit tests to terminate unexpectedly, affecting code coverage statistics and reducing the reliability and stability of CI.
3. Resource Release Risks: System.exit does not trigger the execution of finally code blocks, potentially leading to improperly closed resources such as database connections and file handles.

Rationale

Replace direct System.exit calls with specific exceptions, such as TronError, and handle these exceptions at appropriate higher-level calling points using a unified exit logic. This approach preserves the default exit behavior while addressing the issues above to the greatest extent possible.

[xxo1shine]

@halibobo1205  Can replacing direct System.exit calls with specific exceptions solve the above problem? How to exit the process specifically?

[S1ep]

What is the meaning of CI of the 2nd technical debt in Background?

[CarlChaoCarl]

@halibobo1205

Directly calling System.exit prevents the Spring application from shutting down gracefully. Looking forward to this optimization.

[halibobo1205]

@halibobo1205  Can replacing direct System.exit calls with specific exceptions solve the above problem? How to exit the process specifically?

@xxo1shine Handle these exceptions at appropriate higher-level calling points using a unified exit logic, maintaining the same exit logic as before, except that the exit position changes.

[halibobo1205]

What is the meaning of CI of the 2nd technical debt in Background?

@S1ep
Continuous integration (CI) is a process in which developers continually commit code in small increments—sometimes multiple times a day—which is then automatically built and tested before it is merged with the shared repository.

The main goal of CI is to provide quick feedback so that if a defect is introduced into the code base, it can be identified and corrected as soon as possible. CI helps reduce the time and effort required for integration problems and allows developers to enhance software quality continuously.

[Murphytron]

This issue has been added to the tronprotocol/pm#107, welcome to share the latest progress @halibobo1205, and discuss together with @xxo1shine @S1ep @CarlChaoCarl

[angrynurd]

2 simple questions:
1.How can we ensure that critical resources such as network connections and file handles are properly and promptly released after replacing System.exit calls in the Java-Tron project?
2.How can we design and implement a classification and priority handling system for exceptions in the new error management framework to ensure that the system shuts down in an orderly and reasonable manner under different error scenarios?

[halibobo1205]

@angrynurd

1. Resources are properly and promptly released by finally code blocks or triggered by ShutdownHook
2. Set global exception handler by Thread.setDefaultUncaughtExceptionHandler, use an independent thread for System.exit, shuts down in an orderly is managed by Spring.

     Thread.setDefaultUncaughtExceptionHandler((t, e) -> {
        findTronError(e).ifPresent(this::logAndExit);
   });

   private void logAndExit(TronError exit) {
        final int code = exit.getCode();
        logger.error("Shutting down with code: {}.", code, exit);
       Thread exitThread = exitThreadFactory.newThread(() -> System.exit(code));
       exitThread.start();
 }