Proposed API for JEP 259: Stack-Walking API
david.holmes at oracle.com
Fri Nov 20 02:12:22 UTC 2015
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.
> 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.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.
More information about the core-libs-dev