[jira] [Commented] (IO-830) Rethink AbstractOrigin

["Jochen Wiedmann (Jira)" <ji...@apache.org>]

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