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

Am 06.07.2018 um 22:04 schrieb Olaf Klinke:

...

Am 05.07.2018 um 22:39 schrieb Olga Ershova :

On Thu, Jul 5, 2018 at 4:27 PM Olaf Klinke 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