On 28/06/13 02:38, Stuart Marks wrote:
On 6/27/13 4:58 PM, Brad Wetmore wrote:
Chris (and Michael),
As my part of the "intermittently failing test cleanup," I'm looking
into a
test of yours that has been intermittently failing.
It's bug:
https://jbs.oracle.com/bugs/browse/JDK-8017333
The open URL to view this bug is:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017333
which is failing the regression test you added for:
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8a143213c65
You used a really old version of the test framework (pre-2003!) which
doesn't
output both the client and server exceptions. I've updated the test
to use the
new framework, and would like to put this back as a temporary measure
so we can
see what is really happening from any possible swallowed exceptions.
Xuelei/I are stumped as to what might be happening, so hopefully this
action
will give some clarity.
8019341: Update CookieHttpsClientTest to use the newer framework.
http://cr.openjdk.java.net/~wetmore/8019341/webrev.00/
Improving the exception handling seems mostly reasonable.
It looks like startServer() and startClient() now both try to catch
any exceptions and store them in variables for later processing. But
they still are declared to throw Exception, and the code that calls
them from the constructor throws away any exception that's caught
there. Hm, it's hard to know what exception might be caught at that
point, but since we don't really know what's going on, we probably
shouldn't rule anything out.
Most places catch Exception. One possibility to consider is whether an
Error of some type might be thrown, which isn't caught by "catch
(Exception)" clauses.
In the place where you potentially have two exceptions to report, you
might consider using the suppressed exception mechanism. This is
bending the semantics a bit, but if the client is subordinate to the
server (or vice versa) and both throw exceptions, only one can be
propagated, so it could seem somewhat proper to consider one exception
to have suppressed the other.
I'd agree with this. If the exception is being swallowed now, how will
we know when
the test fails?
Also, I don't see where the change is invoking the newer framework? Am I
looking
at the right webrev?
Michael
It would be easiest to compare your test to the
test/sun/security/ssl/templates/SSLSocketTemplate.java. They should
be the
same except for your test-specific code.
Hm, a template-based framework? Might be worth investigating turning
this into a library at some point.
Brad
P.S. I think AlanB/JoeD/StuartM will appreciate this effort. ;)
Yes, indeed. :-)
s'marks
