Proposed API for JEP 259: Stack-Walking API

[Timo Kinnunen]

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.holmes at 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