refactor(config): improve startup errors and remove inactive assertions

[bladehan1]

What does this PR do?

• Replace selected startup IllegalArgumentException failures with TronError(PARAMETER_INIT).
• Remove selected historical Java assertions that are inactive under the default production JVM configuration.
• Preserve the assertions in the EthereumJ-derived TrieImpl and the Besu-derived Blake2bfMessageDigest implementations.
• Add focused unit and integration tests for the affected configuration error paths.

Why are these changes required?

The selected failures are parameter initialization errors. Classifying them with PARAMETER_INIT makes startup failures consistent while preserving their messages and exit behavior.

The assertion cleanup is limited to historical java-tron code where the assertions are inactive by default. Assertions in TrieImpl are retained because its core implementation is derived from EthereumJ and the checks document internal node-type invariants. The Besu-derived Blake2bf assertion is retained for the same upstream-maintenance reason. Keeping these assertions avoids unnecessary divergence from their source implementations; replacing them with production runtime checks, if required, should be evaluated separately.

This PR has been tested by:

• Unit tests:
  • ./gradlew :common:test --tests org.tron.core.config.args.CommitteeConfigTest
  • ./gradlew :framework:test --tests org.tron.core.config.args.ArgsTest
  • ./gradlew -g /private/tmp/java-tron-gradle-home :framework:test --tests org.tron.core.tire.TrieTest
• Coverage reports:
  • ./gradlew :common:jacocoTestReport :framework:jacocoTestReport
  • Verified zero missed instructions for CommitteeConfig.java:166 and Args.java:1048,1092.
• Checkstyle:
  • ./gradlew :framework:checkstyleTest
• Whitespace validation:
  • git diff --check

Follow up

Other startup failures and any replacement of upstream-derived assertions with explicit runtime checks should be evaluated separately according to their semantics and performance impact.

Extra details

• Valid configuration and Trie behavior are unchanged.
• No protocol, database, network, or performance impact is expected.
• TrieImpl and Blake2bfMessageDigest are excluded from the assertion-removal scope.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: dbd36f24-eab0-4a62-a355-d63a1bfbb793

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[bladehan1]

Automated review by the Codex review pipeline.

Decision: Approve with one concern
Findings: P0=0, P1=1, P2=0, nit=0

NOTE: This review contains AI suggestions; human reviewers retain final judgment.

[cubic-dev-ai]

1 issue found across 8 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="actuator/src/main/java/org/tron/core/vm/repository/RepositoryImpl.java">

<violation number="1" location="actuator/src/main/java/org/tron/core/vm/repository/RepositoryImpl.java:976">
P2: This assertion is not inactive/historical code — it guards division by totalEnergyWeight on the very next lines. If totalEnergyWeight is 0, the hardened path throws a bare ArithmeticException and the non-hardened path silently yields an unbounded value from `(long)(... / 0.0)` (Long.MAX_VALUE). The PR limits removal to dead asserts and retains critical ones; this one is live protection in a core resource method, so keeping it (or an explicit zero check) preserves the safety net rather than deleting it.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: This assertion is not inactive/historical code — it guards division by totalEnergyWeight on the very next lines. If totalEnergyWeight is 0, the hardened path throws a bare ArithmeticException and the non-hardened path silently yields an unbounded value from (long)(... / 0.0) (Long.MAX_VALUE). The PR limits removal to dead asserts and retains critical ones; this one is live protection in a core resource method, so keeping it (or an explicit zero check) preserves the safety net rather than deleting it.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At actuator/src/main/java/org/tron/core/vm/repository/RepositoryImpl.java, line 976:

<comment>This assertion is not inactive/historical code — it guards division by totalEnergyWeight on the very next lines. If totalEnergyWeight is 0, the hardened path throws a bare ArithmeticException and the non-hardened path silently yields an unbounded value from `(long)(... / 0.0)` (Long.MAX_VALUE). The PR limits removal to dead asserts and retains critical ones; this one is live protection in a core resource method, so keeping it (or an explicit zero check) preserves the safety net rather than deleting it.</comment>

<file context>
@@ -973,8 +972,6 @@ public long calculateGlobalEnergyLimit(AccountCapsule accountCapsule) {
-    assert totalEnergyWeight > 0;
-
     if (hardenResourceCalculation()) {
       return BigInteger.valueOf(energyWeight)
           .multiply(BigInteger.valueOf(totalEnergyLimit))
</file context>