Code Review Request 7187876: ClassCastException in TCPTransport.executeAcceptLoop (original) (raw)
Stuart Marks stuart.marks at oracle.com
Thu Aug 2 02:19:32 UTC 2012
- Previous message: hg: jdk8/tl/jdk: 6844255: Potential stack corruption in GetJavaProperties
- Next message: Code Review Request 7187876: ClassCastException in TCPTransport.executeAcceptLoop
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 7/30/12 4:43 PM, David Holmes wrote:
On 31/07/2012 8:27 AM, Darryl Mocek wrote:
Hello core-libs. Please review this webrev to fix Bug #7187876. Webrev can be found here: http://cr.openjdk.java.net/~dmocek/7187876/webrev.00.
The rmi/transport/acceptLoop/CloseServerSocketOnTermination.java test throws ClassCastException due to the Throwable not being of type Error in TCPTransport. Just wondering what type it was? Something that extends Throwable directly? This: throw new Error(t.getMessage(), t.getCause()); loses the type of exception that was thrown. It is better to use: throw new Error(t);
The suggestion to use new Error(t) is a good one.
This case is kind of pathological. The CloseServerSocketOnTermination test injects an exception of an arbitrary type into the accept loop of an RMI connection. (See the test to see how it does this; it's rather clever.) The cast error occurs when the exception that's injected is an instance of Throwable.
Oh, one more thing. Mike Duigou pointed out to me that there is something called UndeclaredThrowableException. Should we throw new UndeclaredThrowableException(t) instead?
s'marks
- Previous message: hg: jdk8/tl/jdk: 6844255: Potential stack corruption in GetJavaProperties
- Next message: Code Review Request 7187876: ClassCastException in TCPTransport.executeAcceptLoop
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]