Adding binary to the Haskell Platform

Johan Tibell johan.tibell at gmail.com
Thu Aug 6 02:42:30 EDT 2009


On Wed, Aug 5, 2009 at 10:47 PM, Don Stewart<dons at galois.com> wrote:
> alexander.dunlap:
>> On Wed, Aug 5, 2009 at 1:34 PM, Don Stewart<dons at galois.com> wrote:
>> > alexander.dunlap:
>> >> To add to the laundry list of problems with Data.Binary, I don't like
>> >> the fact that decode calls error on invalid input. I can't think of
>> >> any great alternatives (using Maybe as the result type would be too
>> >> strict, of course, and returning partial results would be difficult
>> >> with polymorphism), but it seems a bit unclean that decode has to be
>> >> used with the IO monad to catch the errors. (Of course, the only
>> >> reason you would have bad input would be if you were using the IO
>> >> monad, so the practical implications are not great, but still, it
>> >> would be nice if there was a better way.)
>> >
>> > That's right. Originally, it used a custom Either type, but it isn't
>> > possible to stream decoders that way.
>> >
>> > I'd consider it an intentional design feature.
>> >
>> > -- Don
>> >
>>
>> OK. Would it be worth creating an extensible exception (something like
>> BinaryDecodeError) for this then, instead of using the call to error?
>> That would at least make it less error-prone to catch.
>>
>
> I think that would be a good idea. Showing how to catch it in the
> documentation.
>
> I'm wary of breaking the 70 packages that use Data.Binary for this,
> rather, add this as a list of API changes for the next major release.

Would this really break that many libraries? Are there many libraries
that catch the exception that can be raised by error?

Cheers,

Johan


More information about the Libraries mailing list