Reading/writing goto binaries: consistently use return values

[tautschnig]

Always use the return value to communicate errors, not a mix of return values and exceptions.

• Each commit message has a non-empty body, explaining why the change was made.
• Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• n/a The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
• Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
• n/a My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[codecov]

Codecov Report

❌ Patch coverage is 31.57895% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.39%. Comparing base (2e6200a) to head (3b0409b).

Files with missing lines	Patch %	Lines
src/goto-programs/write_goto_binary.cpp	9.09%	10 Missing ⚠️
src/goto-harness/goto_harness_parse_options.cpp	25.00%	3 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #7643      +/-   ##
===========================================
- Coverage    80.39%   80.39%   -0.01%     
===========================================
  Files         1688     1688              
  Lines       207403   207411       +8     
  Branches        73       73              
===========================================
+ Hits        166749   166751       +2     
- Misses       40654    40660       +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[peterschrammel]

Is this an improvement?

[tautschnig]

Using return values rather than exceptions? I'd argue yes for two reasons:

1. It is consistent across reading (which already did this) and writing (which now does this) goto binaries.
2. Using return values to communicate errors makes it easier to build (cross-language) APIs.