title: UnsupportedOperationException vs IllegalStateException in an immutable (pure functional) context
body: <p>The general case of when one should be used vs another has been covered by question <a href="https://stackoverflow.com/questions/49749786/illegalstateexception-vs-unsupportedoperationexception">IllegalStateException vs UnsupportedOperationException</a>. I agree completely with the accepted answer by davidxxx, as it is how I have always used both:</p>
  <blockquote>
  <p>UnsupportedOperationException should be used as the method is not supported at all while IllegalStateException should be used as the method is supported but that in the current state, it is not legal.</p>
  </blockquote>
  <p>The distinction becomes however quite muddy in functional programming: normally, in imperative OO languages, 'not supported at all' is understood in terms of a polymorphic subclass. In functional languages, even supporting OO programming and featuring <em>classes</em> as a code unit, they have traditionally slightly less weight opposed to the process of their instantiation. If an object is immutable and a certain operation cannot be completed at any time, it never will, which is not really that much different from receiving an instance of a more specific class in an OO language. At the same time, the concept of 'application state' mentioned in the documentation of <code>IllegalStateException</code> still exists, but I find it somewhat misleading in the context of that single object and a bit out of place in a functional language. That said, a user seeing an <code>UnsupportedOperationException</code> thrown might follow the <em>Java</em> policy and assume the method is not invocable on the given class under any circumstances.</p>
  <p>I understand that it is to a certain extend opinion-based in general, so I would like to ask specifically if there is a consensus in usage between standard libraries of <em>Scala</em> and <em>F#</em> or a precedent set by large, widely used OS projects? I would like to settle on a single, well defined scheme that follows the policy of least surprise.</p>