[#270] Audit issue C: Properly check read()

[HonzaR]

Closes #270

Note
This code review checklist is intended to serve as a starting point for the author and reviewer, although it may not be appropriate for all types of changes (e.g. fixing a spelling typo in documentation). For more in-depth discussion of how we think about code review, please see Code Review Guidelines.

Author

• Self-review your own code in GitHub's web interface¹
• Add automated tests as appropriate
• Check the code coverage² report for the automated tests
• Update documentation as appropriate (e.g README.md, etc.)
• Pull in the latest changes from the main branch and squash your commits before assigning a reviewer³

Reviewer

• Check the code with the Code Review Guidelines checklist
• Perform an ad hoc review⁴
• Review the automated tests
• Review the documentation, README.md, etc. as appropriate

Footnotes

1. Code often looks different when reviewing the diff in a browser, making it easier to spot potential bugs. ↩

2. While we are not looking for perfect coverage, the tool can point out potential cases that have been missed. Code coverage can be generated with: ./gradlew check. ↩

3. Having your code up to date and squashed will make it easier for others to review. Use best judgement when squashing commits, as some changes (such as refactoring) might be easier to review as a separate commit. ↩

4. In addition to a first pass using the code review guidelines, do a second pass using your best judgement and experience which may identify additional questions or comments. Research shows that code review is most effective when done in multiple passes, where reviewers look for different things through each pass. ↩