[
https://issues.apache.org/jira/browse/TIKA-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved TIKA-104.
--------------------------------
Resolution: Fixed
Fix Version/s: 0.1-incubator
Assignee: Jukka Zitting (was: Chris A. Mattmann)
I think an IOException subclass is a cleaner way to do this, as it doesn't
introduce an extra frame in the exception stack trace.
I implemented a new CauseIOException class for this and committed the adapted
patch in revision 606139. Feel free to override if you think the util method
approach is better for this.
Thanks, Niall, for this improvement! We should probably get the utils method or
CauseIOException included in commons-io, where it could better be reused by
other projects. I'll take a look at that.
> Add utility methods to throw IOException with the caused intialized
> -------------------------------------------------------------------
>
> Key: TIKA-104
> URL: https://issues.apache.org/jira/browse/TIKA-104
> Project: Tika
> Issue Type: Improvement
> Components: general
> Reporter: Niall Pemberton
> Assignee: Jukka Zitting
> Priority: Minor
> Fix For: 0.1-incubator
>
> Attachments: TIKA-104-throwIOException-v1.patch
>
>
> The constructors with a Throwable cause were not added until JDK 1.6 - I
> suggest adding a utility method to intialize the cause in the IOException.
> This can be used to revert r596143[1] (and similar situation in
> AppendableApdaptor) so that the cause is not swallowed.
> [1] http://svn.apache.org/viewvc?view=rev&revision=596143
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
