[ 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)