Skip to content

Optimize System.exit Usage #6125

Closed
Closed
@halibobo1205

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions