It would be easier to deal with errors if the error kind is made pub

[asahaf]

Hi,

Some errors, like closed, column, and row_count, don't have a cause (None). for these errors, there is no way to know the actual underlayer error as the error kind is not exposed.
It would be easier if the error kind is made public.

Thanks,

[hhirtz]

Duplicate of #571?

[hn-sl]

Any update? This is absolutely necessary to handle error properly when cause is None.

[hhirtz]

I mean if it's a matter of removing 4 chars from a file anyone concerned could send a patch.

[palfrey]

For reference, I'd be interested in knowing about the ConfigParse case as I've got a hacky workaround for this right now.

[couchand]

I've run into this from the same place @palfrey seems to: trying to figure out if it's worth retrying the request (c.f. djc/bb8#141). @sfackler would you be open to a PR simliar to #739 that exposes a method with this information?

One possible difficulty is identifying which kinds of errors should be included. @palfrey's workaround looks for Kind::ConfigParse errors, and @levi-nz's issue implies Kind::Authentication should be included. In a quick review of the enum variants, none stand out to me, but perhaps there are others?