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: 31.57% and project coverage change: -0.03 ⚠️

Comparison is base (ba47c86) 78.55% compared to head (d694622) 78.53%.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #7643      +/-   ##
===========================================
- Coverage    78.55%   78.53%   -0.03%     
===========================================
  Files         1686     1686              
  Lines       192923   192929       +6     
===========================================
- Hits        151552   151515      -37     
- Misses       41371    41414      +43     

Impacted Files	Coverage Δ
src/goto-programs/write_goto_binary.cpp	79.36% <9.09%> (-5.64%)	⬇️
src/goto-harness/goto_harness_parse_options.cpp	75.92% <25.00%> (-2.17%)	⬇️
src/goto-analyzer/static_simplifier.cpp	87.50% <100.00%> (ø)
src/goto-cc/compile.cpp	73.55% <100.00%> (ø)
src/symtab2gb/symtab2gb_parse_options.cpp	60.52% <100.00%> (ø)

... and 2 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

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