[
https://issues.apache.org/jira/browse/IO-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847387#comment-17847387
]
Jochen Wiedmann commented on IO-830:
------------------------------------
[~elharo] While I agree with you, in general (for example, I'd like to see a
distinction between an origin, that is based on a byte stream, and an origin,
that is based on a character stream), I don't see any real pain. The mere fact,
that an UnsupportedOperationException is being used, is (in my opinion) not
enough reason to implement changes.
In particular, as far as I can tell, the UOE isn't actually thrown, but just
declared in the Javadocs.
> Rethink AbstractOrigin
> ----------------------
>
> Key: IO-830
> URL: https://issues.apache.org/jira/browse/IO-830
> Project: Commons IO
> Issue Type: Bug
> Reporter: Elliotte Rusty Harold
> Priority: Critical
>
> UnuspportedOperationException is a code smell that indicates the class
> hierarchy doesn't really fit the problem and violates the Liskov Subsitution
> Principle
> See
> https://softwareengineering.stackexchange.com/questions/337850/is-expecting-the-api-user-to-implement-an-unsupportedoperationexception-okay
> It doesn't work to treat all origins the same. E.g. CharSequences really,
> really need a character set before they can be converted to byte arrays or
> input streams, but byte arrays and files don't. In reverse files need a
> character set to be converted to a reader but char sequences don't.
> Different classes need different arguments, whether you use a builder or a
> constructor. There's not common type here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
