A point in favor of UnsupportedOperationException would be: if in the future it becomes possible to have large parts of the JVM written in Java or sun.tools becomes part of the J2SE API then having an instance of a VirtualMachine class as the caller of public static void main and Thread.run could be completely true and natural. Changing getCallerClass to support this and not throw an UOE feels less of a breaking change than it no longer throwing an IllegalStateException. Especially since no state that the caller can affect has actually changed!
Sent from Mail for Windows 10 From: John Rose Sent: Thursday, November 19, 2015 05:45 To: David Holmes Cc: OpenJDK Dev list Subject: Re: Proposed API for JEP 259: Stack-Walking API On Nov 18, 2015, at 6:32 PM, David Holmes <david.hol...@oracle.com> wrote: > >>> >>> Looks good to me too if IllegalStateException is used instead of >>> UnsupportedOperationException. >>> UnsuppportedOperationException is used when the operation is not >>> available, here, the same code can work or not depending how it is >>> called. >> >> But IllegalStateException is dependent on some state. There's no state >> involved here (in the sense "state" is characterized in Java). My 1st > > I agree with Remi. "state" doesn't have to mean fields - there are numerous > existing examples in the JDK. Calling a method in a context that is invalid > is an illegal state to me. IllegalThreadStateException would also work. But > UnsupportedOperationException ... more of a stretch. +1
