[Haskell-cafe] Bool is not...safe?!
jo at durchholz.org
Fri Jul 6 20:35:57 UTC 2018
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
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.
More information about the Haskell-Cafe