[Haskell-cafe] Extensible Exceptions

[Henning Thielemann]

On Sun, 23 Nov 2008, Duncan Coutts wrote:

> On Sun, 2008-11-23 at 01:40 +0100, Henning Thielemann wrote:
>> On Sat, 22 Nov 2008, Thomas Schilling wrote:
>>
>>> It's a pattern match error, implemented by throwing an asynchronous
>>> exception.  The idea being, that we only have one mechanism (well, an
>>> synchronous exceptions, thrown via throwIO).
>>>
>>> Yes, I know that there's a difference between "error" and "exception",
>>> but I would argue that which is which depends on the program.  For
>>> example, for most programs a pattern match error is a fatal condition,
>>> there's no sane recovery from it.  OTOH, in a program like GHCi, a
>>> pattern match error in an executed statement is an exceptional
>>> condition, which we want to catch, so it doesn't kill GHCi.
>>
>> It's completely ok to run something in a sandbox and try to observe
>> errors. But that's debugging and I think there is no need to do this in
>> many places of an application. In general handling errors automatically is
>> not possible, because an error might also be if a program loops
>> infinitely. Thus one should not generally handle an error like an
>> exception.
>
> In general I agree. I would advise against explicitly catching such
> exceptions just in the region where one is expecting them. That seems
> like bad design.
>
> On the other hand "top level" catch-all handlers that also catch such
> logic errors sometimes make sense. For example in a Haskell web server
> where we generate a page dynamically it makes a lot of sense to catch
> errors in the page-generation function, including pattern match errors,
> and produce a 500 error code response and log the error message.
>
> That's a case, rather like ghci, where some flaw in the program can and
> should be compartmentalised. There's no attempt to clean up the error
> but it is a modular system and there is a clear boundary where failures
> can occur without bringing down the entire system.

full acknowledge