Comparing Exceptions and Errors

[Paul Backus]

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