[Haskell-cafe] Exception handling when using STUArray

Donn Cave donn at avvanta.com
Wed Mar 12 14:17:39 EDT 2008

On Mar 12, 2008, at 6:34 AM, Brandon S. Allbery KF8NH wrote:

> On Mar 11, 2008, at 14:27 , Donn Cave wrote:
>>     readLDAPMessage s = let [(_, msgID), (tag, body)] = berList s in
>>         LDAPMessage (berInt msgID) (readResponse tag body)
>> I go on to account for all the LDAP stuff I need in about 60 lines
>> of that kind of thing, 1/3 of it devoted to declarations of the
>> data types, and it isn't dense code, it's ... essentially  
>> declarative,
>> in a simple, straightforward way, almost as if I copied it directly
>> from the RFC.
>> Is it `total'?  No way!  To get there, it seems to me I'd have to
>> double the code, and significantly distract from its real sense.
> You might want to think about the monadic use of Maybe/Either (or  
> more generally MonadError), which abstracts away the checking and  
> tracking into (>>=).  The error handler is then at the point where  
> values are injected into / retrieved from the monadic exception,  
> similar to catch (...).

Sure.  It isn't a lot of code, so I subjected it to Either-ization
as an experiment, and I did indeed take the monad procedural route.
The example function above became

    readLDAPMessage s = do
        [(_, msgID), (tag, body)] <- berList s >>= exactLen 2
        i <- berInt msgID
        r <- readResponse tag body
        return (LDAPMessage i r)

... and the end result, applying this style across a number of
related functions, was no more than half again as much code,
and I guess not severely unreadable.  Maybe it depends on whether
a procedural style suits you.  There may be clever ways to torture
this logic into an even smaller format, but since the original
is the clearest expression of the protocol and its caller is
almost guaranteed to have an exception handler anyway -- in my
opinion, it was a silly exercise, I'll throw the code away.

The Either version forces strict evaluation, true?  Let's say for
some reason the caller actually uses only the first part, the LDAP
message ID, then we don't really need to validate and decode the
whole message, but if I were to Either-ize it, then it has to go
the whole distance before we know it's Right and not Left?  And
likewise for every value of every attribute in the message.

What I naively picture as the next step, where pure code can
handle exceptions, is an _implicit_ evaluation monad like Either.
Pattern matches then throw exceptions in the sense described in
Control.Monad.Error, which may be caught in pure code by optionally
making the monadic type explicit, or otherwise are converted to
exceptions in the sense of Control.Exception and caught in the
IO monad.  I suppose this would not force evaluation, because it's
fine grained - I don't fold (Right i) and (Right r) into
(Right (LDAPMessage i r)), etc., but rather you may encounter
a (Left _) anywhere in there.  At least this would let us rationalize
the use of 'exception' with two radically different meanings between
Control.Monad.Error and Control.Exception.

	Donn Cave, donn at avvanta.com

More information about the Haskell-Cafe mailing list