homberghp commented on PR #8568: URL: https://github.com/apache/netbeans/pull/8568#issuecomment-4187702824
> would be good to simplify this before the merge. I haven't really tried to reproduce the issue (and compared the behaviour with the modifications here) since this PR has already so many comments, I hope someone did already :) That has been done, for both cases. I am still not fully convinced of the solution. I kept the order of stack iteration as the original, but have no proper explanation why one needs to start at the bottom instead of the top (as defined by `java.langThrowable.getStackTrace()`). Starting at the top appears to be the natural order to follow when trying to find the cause of trouble. In Unit tests, the trouble is typically the failing assert/check/verification (inside the test method). However, I infer from all the checks that occur before we start obtaining the stack trace and before we start the first iteration, that the first loop will always succeed with a file found, for the following reasons: 1. We are in a unit test. 2. It is a JUnitCallStackFrameNode 3. There is a locator that finds a file. 4. There is also a test file object (testfo). 5. There is trouble (thus a stacktrace). 6. Which will contain the stack frame of the test method we are looking for, because it failed and is the cause of 'the trouble'. So the second loop only exists by virtue of defensive programming. I use the natural iteration order in this 2nd loop. > Might want to consider whether `fqMethodName` should include the opening `(` given the use of `String::contains`? That is a valid suggestion. Test methods tend to get similar names, and one name could be the prefix of another. The parentheses avoid that. On the other hand, they should not occur in the same stack trace, although you never know if a test writer 'reuses' tests by having one test call the other. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
