Skip to content
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

Make XLSError a sub-type of XlsException #1

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

olafklinke
Copy link
Owner

Although we can map the original constructors of XlsException to the XLSError enum, various functions throw either of them. We make XLSError a sub-type of XlsException via an extra constructor so that the user only has to worry about catching one Exception type.

Although we can map the original constructors of `XlsException` to the `XLSError` enum, various functions throw either of them. We make `XLSError` a sub-type of `XlsException` via an extra constructor so that the user only has to worry about catching one Exception type.
@@ -129,13 +129,15 @@ CCALL(xls_cell_hidden, XLSCell -> IO Int8 -- Int8)
data XlsException =
XlsFileNotFound String
| XlsParseError String
| Libxls XLSError

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The two cases of XLSError are already represented in XlsException. We can add the other cases as well, something like this:

data XlsException =
      XlsFileNotFound String
    | XlsParseError String
    | XlsSeekError String
    | XlsReadError String 
    | XlsMallocError String

And just translate XLSError to XlsException, and then do not export XLSError.

-- | Experimental: This function uses the @xls_open_buffer@ function of libxls.
decodeXlsByteString' :: ByteString -> IO (Either XLSError [[[Cell]]])
-- | Alternative to 'decodeXlsByteString':
-- This function uses the @xls_open_buffer@ function of libxls.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is hard to understand for users of the library. We can instead say something like:

"This function does not use a temporary file unlike decodeXlsByteString".

BTW, why don't we just use solely this API and remove the other one? Is this not reliable?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants