New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

no non-internal way to catch exception from decompress? #9

Open
elaforge opened this Issue Oct 29, 2016 · 8 comments

Comments

Projects
None yet
5 participants
@elaforge
Copy link

elaforge commented Oct 29, 2016

I was surprised to discover (via a production crash) that Zlib.decompress throws its own exception, not an IOError. Also, it looks like the only place its exception is exported is Codec.Compression.Zlib.Internal, which implies I shouldn't be using it normally.

How about re-exporting the exception from Zlib and GZip, and then augmenting the documentation to say exactly what exception will be thrown? As a bonus it would be nice to have an example, because I initially thought ByteString.Lazy.toStrict should be enough, but you also need an Exception.evaluate in there.

I can make a pull request if you want.

@NorfairKing

This comment has been minimized.

Copy link

NorfairKing commented Mar 12, 2017

+1, would also like a Maybe ByteString or Either ZLibException ByteString version of the API.

@dcoutts

This comment has been minimized.

Copy link
Member

dcoutts commented Mar 29, 2017

The new incremental API is stable enough that we should promote it from the internal module.

@hvr

This comment has been minimized.

Copy link
Member

hvr commented Mar 30, 2017

@dcoutts wait... we still need #6 which would break the compression-side of the API ;-)

@ocramz

This comment has been minimized.

Copy link

ocramz commented Nov 23, 2017

@hvr @dcoutts I think it would be sufficient to export a decompressM that uses foldDecompressStream and some variation of throwM. Explicit exception handling is especially crucial for processing http responses, which are gzipped only if successful. Would you accept such a patch?

@ocramz

This comment has been minimized.

Copy link

ocramz commented Mar 14, 2018

@hvr @dcoutts If I understand correctly, the latest version of zlib released on March 8 doesn't carry add this functionality. Is it in the development plans for the foreseeable future, or could you please advise what other zlib/gzip streaming bindings expose a monadic interface that throws relevant exceptions ?

@hvr

This comment has been minimized.

Copy link
Member

hvr commented Mar 14, 2018

I think there's a good chance that the next one will... personally I'd like to see zlib's API be harmonised with http://hackage.haskell.org/package/lzma-0.0.0.3/docs/Codec-Compression-Lzma.html but I still need to negotiate w/ Duncan :-)

@ocramz

This comment has been minimized.

Copy link

ocramz commented Jul 4, 2018

@dcoutts @hvr is there anything I can do to help with this issue? Perhaps you have an idea on how should the common zlib/lzma interface evolve and can advise for a PR? Thanks!

@ocramz

This comment has been minimized.

Copy link

ocramz commented Jan 26, 2019

Ping !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment