lazily handling exceptions in lazy sources (Re: [Haskell-cafe] Re: Takusen and strictness, and perils of getContents)

Claus Reinke claus.reinke at
Wed Mar 14 11:42:07 EDT 2007

>> Is this really a solution? Currently, getContents reports no errors
>> but does perfect error recovery: the result of the computation prior to
>> the error is preserved and reported to the caller. Imprecise
>> exceptions give us error reporting -- but no error recovery. All
>> previously computed results are lost. Here's a typical scenario:
>> do l <- getContents
>>    return (map process l)
>> If an error occurs reading lazy input, we'd like to log the error and
>> assume the input is terminated with EOF. 
> i was wondering: could you perhaps use the old Hood Observe trick
> to help you out? Hood wraps lazy sources in unsafePerformIO handlers 
> that log things as they are demanded, then passes them on. you might be 
> able to use the same to pass things on as they are demanded, while logging 
> exceptions and replacing exceptional with repaired or default values?

attached is an implementation sketch, with an example problem (a lazily produced
String that never gets its 10th element, and includes an error for every uppercase
Char in the input. with the handlers commented out, we get things like this:

    $ (echo "Hi "; sleep 1; echo "There, World") | runHaskell ResumeCatch.hs
    *** Exception: oops

while replacing str with a handled str (in the definition of safestr) gives:

    $ (echo "Hi "; sleep 1; echo "There, World") | runHaskell ResumeCatch.hs
    ?HERE{- ResumeCatch.hs:30:8-57: Non-exhaustive patterns in function process
    all is well that ends well

the usual caveats about unsafePerformIO apply, so perhaps you wouldn't want
to use this in a database library..

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ResumeCatch.hs
Type: application/octet-stream
Size: 1234 bytes
Desc: not available
Url :

More information about the Haskell-Cafe mailing list