> On Apr 12, 2016, at 1:34 AM, Rémi Forax <fo...@univ-mlv.fr> wrote: > > Hi Mandy, > I really don't like this patch. > > Being forced to call toStackElement to get the line number is counter > intuitive. > I would prefer the two methods to not return Optional but an int and a String > with the same convention as StackElement if the point of this patch is to > remove the dependency to Optional. >
I was expecting the common usage of StackWalker API does not need file name and line number. I think it'd be useful to include StackFrame::getBci (in the future it might include live information like locals etc) and keep the optional stuff and uncommon usage to StackTraceElement. Mandy > Rémi > > > Le 11 avril 2016 23:22:39 CEST, Mandy Chung <mandy.ch...@oracle.com> a écrit : >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.00/index.html >> >> StackFrame::getFileName and StackFrame::getLineNumber are originally >> proposed with the view of any stack walking code can migrate to the >> StackWalker API without the use of StackTraceElement. >> >> File name and line number are useful for debugging and troubleshooting >> purpose. It has additional overhead to map from a method and BCI to >> look up the file name and line number. >> >> StackFrame::toStackTraceElement method returns StackTraceElement that >> includes the file name and line number. There is no particular benefit >> to duplicate getFileName and getLineNumber methods in StackFrame. It is >> equivalently convenient to call >> StackFrame.toStackTraceElement().getFileName() (or getLineNumber). >> >> This patch proposes to remove StackFrame::getFileName and >> StackFrame::getLineNumber methods since such information can be >> obtained from StackFrame.toStackTraceElement(). >> >> Mandy >
