On 19/11/2015 11:36 PM, Timo Kinnunen wrote:
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!
@throws IllegalStateException if called from a context where this is no Java caller present
If you change the VM implementation so there is a Java caller then you don't throw ISE any more. I don't see any issue.
Cheers, David
Sent from Mail <http://go.microsoft.com/fwlink/?LinkId=550986> 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
