JDK 9 RFR of JDK-8023897: Replace/update/rename executeAndCatch in various tests to assertThrows

[Pavel Rappo]

> On 2 May 2017, at 22:02, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
> 
> If the test was being written new I would advocate to add messages that reflect the semantics of
> the test case, not the exception message.
> 
> But ": Must throw ClassCastException for parameter which is not Comparable."
> in Empty navigableMap is much more useful.

Well, okay. I think it's a fair point to have this option available. I for one
once agreed and fully accepted Joshua Bloch's passage [1] on this:

    "...While it is critical to include all of the pertinent "hard data" in the
    detail message of an exception, it is generally unimportant to include a lot
    of prose. The stack trace is intended to be analyzed in conjunction with the
    source files and generally contains the exact file and line number from
    which the exception was thrown, as well as the files and line numbers of all
    other method invocations on the stack. Lengthy prose descriptions of the
    failure are generally superfluous; the information can be gleaned by reading
    the source code.

    The detail message of an exception should not be confused with a user-level
    error message, which must be intelligible to end users. Unlike a user-level
    error message, it is primarily for the benefit of programmers or field
    service personnel for use when analyzing a failure. Therefore, information
    content is far more important than intelligibility..."

> And wrapping exceptions in exceptions makes debugging much harder, because
> it requires unwrapping the context and figuring out what the test was trying to
> do and which was the relevant source line.  Here I would advocate for the test author
> to make sure the diagnostic information is direct and informative and not obscured
> by stack traces and too much irrelevant detail.

I think a stacktrace is an enormously valuable piece of information to have in
logs of a test run. It shows you where exactly a thing happened without any
effort on your side.

One more thing. I don't know much about TestNG, but IIRC JUnit used
java.lang.AssertionError (or its subclass) for the framework's internal
mechanics. So to a various utilities (test report generators, test report
analyzers, etc.) an AssertionError thrown from inside a test meant a specific
thing. Quite different from what any other Throwable meant. I'm not saying I
agree with this design (it probably should've been a separate private exception)
I'm just saying. TestNG might use a similar approach.

> I should probably try to file a bug against TestNG.assertThrows to add a variant with
> a message. Many/most of the TestNG asserts have variants with messages.

+1

Thanks.

--------------------------------------------------------------------------------
[1] Effective Java(TM), Second Edition, Item 63