On Saturday, 4 June 2022 at 22:03:08 UTC, kdevel wrote:
On Saturday, 4 June 2022 at 14:05:14 UTC, Paul Backus wrote:
This is entirely a question of API design. If it should be the
caller's responsibility to check for some condition before
calling the function, then you can throw an `Error` when that
condition does not hold (or more likely, use an `assert` or an
`in` contract to check for it).
Provided one does not catch `Error`s this means one has to
isolate such an API design by using a subprocess. This is what
one usually tries to avoid.
See here:
http://joeduffyblog.com/2016/02/07/the-error-model/#bugs-arent-recoverable-errors
And also the following section:
http://joeduffyblog.com/2016/02/07/the-error-model/#reliability-fault-tolerance-and-isolation
If it should be the callee's responsibility to check, you
should throw an `Exception` (or use `enforce`).
If the library always throws exceptions it can be used in both
API "designs". In the case that the implementor of the caller
expects `Error`s instead of `Exceptions` she could use a small
wrapper which catches the Exceptions and rethrows them as
`Error`s. Likewise for error codes.
Using contracts and invariants impedes this approach.
See here:
https://bloomberg.github.io/bde-resources/pdfs/Contracts_Undefined_Behavior_and_Defensive_Programming.pdf
