[Haskell-cafe] Bool is not...safe?!

[Joachim Durchholz]

Am 06.07.2018 um 22:04 schrieb Olaf Klinke:
> 
>> Am 05.07.2018 um 22:39 schrieb Olga Ershova <blaze at ruddy.ru>:
>>
>>
>>
>> On Thu, Jul 5, 2018 at 4:27 PM Olaf Klinke <olf at aatal-apotheke.de> wrote:
>> Does anyone know whether the C and C++ folks are now using more informative structs as return types?
>>   
>> When returning errors, they call them "exceptions".

True but not really.
C does not have exceptions, so C APIs have always been returning 
discriminated unions.
C++ exceptions tend to be used in different ways, sometimes like Olga 
says, sometimes differently.

> Quite so. One might say that the equivalent of try...catch blocks in Haskell is the pattern match
> 
> case (action :: Either err a) of
>    Right result -> ...
>    Left err -> deal_with err

That's kind of how "checked exceptions" in Java work: You declare them 
in the function signature.

> But what keeps bugging me about exceptions is this: When working with libraries having nested dependencies, is there a way of knowing the complete set of exceptions that might be thrown by a block of code?

So for checked exceptions you know what may go up.
I.e. it's really equivalent to pattern matching.

"Unchecked" exceptions are not declared.
I.e. you can use them as untyped pattern match.

> It is generally considered bad style to write a catch-all. Instead, only catch the exceptions you know how to deal with. But if I don't know
what can be thrown, then I can not make my code bullet-proof. The
explicit return type seems the clearer approach to this problem.

Not generally actually.
At the top level, you do indeed catch all exceptions, as a signal that 
the called computation failed.
Typical reactions to that are:
- Abort the program.
- Log the error and wait for the next request (background programs).
- Report an error message to the user (interactive programs).
- Retry (a useful strategy if nondeterminism is involved).
- Fall back to a simpler strategy (for really large software systems).
Some design philosophies do this not just at the top level, but at each 
intermediate level. Some systems are built using "monitor layers", 
modules that do this kind of subtask monitoring and report an exception 
only if retrying or falling back didn't work.

Regards,
Jo