no non-internal way to catch exception from decompress?

[elaforge]

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]

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

[dcoutts]

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

[hvr]

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

[ocramz]

@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]

@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]

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]

@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]

Ping !

[adamglowacki]

What are the plans? I would appreciate either providing a safe decompress function or moving streaming functions out of .Internal. So that I feel more confident when using them...

[Bodigrim]

No plans, unless someone is passionate enough to prepare a PR for discussion.

[adamglowacki]

I would just export some stuff from internal module. Technically I can use it no matter what's the name and that's what I did. But if it's no longer "internal", I can sleep sound not being afraid that one day it will be changed without a warning. I pinpoint the exact versions with stack but... Let's lower the chances of breaking compatibility if one from my team wants to upgrade the lib version in the future. 27 Oct 2023 19:34:40 ˌbodʲɪˈɡrʲim ***@***.***>:

…

No plans, unless someone is passionate enough to prepare a PR for discussion. — Reply to this email directly, view it on GitHub[#9 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AAI2BQNTHLKDNDRA5DCTUSDYBPWAJAVCNFSM4CUP62JKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZYGMZDOMZZGQ3A]. You are receiving this because you commented. [Tracking image][https://github.com/notifications/beacon/AAI2BQJUSRIL5RA7A3UP6TTYBPWAJA5CNFSM4CUP62JKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGONJFJTWQ.gif]

[Bodigrim]

But if it's no longer "internal", I can sleep sound not being afraid that one day it will be changed without a warning.

I don't follow. What makes you think that Codec.Compression.Zlib.Internal is less stable than the rest of the package?

[adamglowacki]

The name suggests to me that the stuff there is considered internal to the package. It's not a part of the API intended to be used by end-users. It's like an implementation detail that could be changed any time. But maybe I an wrong.. 30 Oct 2023 20:22:37 ˌbodʲɪˈɡrʲim ***@***.***>:

…

But if it's no longer "internal", I can sleep sound not being afraid that one day it will be changed without a warning. I don't follow. What makes you think that *Codec.Compression.Zlib.Internal* is less stable than the rest of the package? — Reply to this email directly, view it on GitHub[#9 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AAI2BQIWNES4SYI7TU7LLYLYB744BAVCNFSM4CUP62JKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZYGU4DSMJQGY3Q]. You are receiving this because you commented. [Tracking image][https://github.com/notifications/beacon/AAI2BQM2OVQ6FW7KF6QH56TYB744BA5CNFSM4CUP62JKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGONJZIR6Y.gif]

[Bodigrim]

I still don't get the link between "internal" aka "low-level interface" and supposed stability.

Any part of this package could be changed at any time, no hard guarantees indeed. The only promise is that such change will be properly reflected by bumping the major version, as PVP requires, and *.Internal namespace is no different.

[adamglowacki]

Oh, that's good. I thought *.Internal is excluded. That's great, I shouldn't worry. 30 Oct 2023 21:54:32 ˌbodʲɪˈɡrʲim ***@***.***>:

…

I still don't get the link between "internal" aka "low-level interface" and supposed stability. Any part of this package could be changed at any time, no hard guarantees indeed. The only promise is that such change will be properly reflected by bumping the major version, as PVP requires, and **.Internal* namespace is no different. — Reply to this email directly, view it on GitHub[#9 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AAI2BQI62LEIXVL2GJQ27LTYCAHXVAVCNFSM4CUP62JKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZYGYYDEMZTGQZA]. You are receiving this because you commented. [Tracking image][https://github.com/notifications/beacon/AAI2BQLLO6ARLI2I7XODNELYCAHXVA5CNFSM4CUP62JKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGONJ2I3LQ.gif]

[Bodigrim]

Fixed in 10f8392.