Hi Amy,
Thanks a lot for doing this! I personally think it's a beginning of a very
valuable refactoring to our test base. It turns out this little piece of
functionality, namely, checking that a particular exception is thrown from code
is error-prone. I have seen many buggy implementations defective in one way or
another. What's worse is that sometimes many of them coexist in the same code
base. Even in the JDK this beast has many names:
tryCatch, verifyException, expectThrows, checkException, expectThrow,
assertThrows, THROWS, check, uncaughtException, testThrowException,
assertSecurityException, ...
This list does not include countless ad-hoc bare try-catch constructs. After
this has been done, I would go even further, and in some cases change tests that
use @Test(expectedException=...) annotation to use this method instead.
Looks good. Wait for a Reviewer and you are good to go.
Thanks,
-Pavel
> On 2 May 2017, at 10:19, Amy Lu <amy...@oracle.com> wrote:
>
> Please review this test-only change.
>
> Some java/util tests use a function executeAndCatch which essentially asserts
> that an exception is thrown, while some other tests use assertThrows for
> doing the same work. For both cases, with jtreg upgraded to testng 6.9.5
> (CODETOOLS-7901639), test can then leverage TestNG Assert.assertThrows
>
> Please review the patch to update executeAndCatch and assertThrows to
> Assert.assertThrows for java/util testng tests.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8023897
> webrev: http://cr.openjdk.java.net/~amlu/8023897/webrev.00/
>
> Thanks,
> Amy
>
