hiero-ledger / hiero-ledger/hiero-consensus-node
Audit use of `OrThrow()` vs `OrElse()` throughout codebase
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 407
- Forks
- 226
- Avg merge
- 3d 4h
- Merged PRs (30d)
- 210
Description
### Problem
When accessing a nullable PBJ field, we can either:
1. Implicitly assert it is non-null via `OrThrow()`; or,
2. Use a default value (say, `Type.DEFAULT`) in the null case via `OrElse()`.
As long as the following business logic has the correct semantics given `Type.DEFAULT`, this is fine.
(A possible example of business logic that has **incorrect** semantics given e.g. `AccountID.DEFAULT` would be logic that saves this default id into state.)
### Solution
Do a comprehensive audit of these accessor usage patterns.
### Alternatives
_No response_
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files, tests, or entry points are named. Start with a repository-wide search for OrThrow() and OrElse(), then inspect each use in its surrounding business logic to determine whether the default value has valid semantics. Done means the comprehensive audit has identified and addressed every problematic accessor usage.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- distributed-systems
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100