[Haskell] Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative
michael at snoyman.com
Mon Aug 23 22:58:17 EDT 2010
It's not released yet, but persistent 0.2 is going to be using enumerator. I
personally don't mind SomeException as a hard-coded error type, but go ahead
and do whatever you think is best for the API.
On Tue, Aug 24, 2010 at 5:47 AM, John Millikin <jmillikin at gmail.com> wrote:
> After fielding some more questions regarding error handling, it turns
> out that my earlier mail was in error (hah) -- error handling is much
> more complicated than I thought.
> When I gave each iteratee its own error type, I was expecting that
> each pipeline would have only one or two sources of errors -- for
> example. a parser, or a file reader. However, in reality, it's likely
> that every single element in a pipeline can produce an error. For
> example, in a JSON/XML/etc reformatter (enumFile, parseEvents,
> formatEvents, iterFile), errors could be SomeException, ParseError, or
> Futhermore, while it's easy to change an iteratee's error type with
> just (e1 -> e2), changing an enumerator or enumeratee *also* requires
> (e2 -> e1). In other words, to avoid loss of error information, the
> two types have to be basically the same thing anyway.
> I would like to avoid hard-coding the error type to SomeException,
> because it forces libraries to use unsafe/unportable language features
> (dynamic typing and casting). However, given the apparent practical
> requirement that all iteratees have the same error type, it seems like
> there's no other choice.
> So, my questions:
> 1. Has anybody here successfully created / used / heard of an iteratee
> implementation with independent error types?
> 2. Do alternative Haskell implementations (JHC, UHC, Hugs, etc)
> support DeriveDataTypeable? If not, is there any more portable way to
> define exceptions?
> 3. Has anybody actually written any libraries which use the existing
> "enumerator" error handling API? I don't mind rewriting my own
> uploads, since this whole mess is my own damn fault, but I don't want
> to inconvenience anybody else.
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe