[
https://issues.apache.org/jira/browse/CASSANDRA-16101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17197079#comment-17197079
]
David Capwell commented on CASSANDRA-16101:
-------------------------------------------
One potential would be to add a method to cluster that resets the exceptions
list and throws if one is found; could make sure all tests call that (and close
would do the same)
Tested how CI would work in this model
{code}
@Test
public void happyTest()
{
System.out.println("happy");
}
@After
public void after()
{
throw new RuntimeException("YOLO");
}
{code}
{code}
[junit-timeout] Testcase:
happyTest(org.apache.cassandra.distributed.test.ClientNetworkStopStartTest):
Caused an ERROR
[junit-timeout] YOLO
[junit-timeout] java.lang.RuntimeException: YOLO
[junit-timeout] at
org.apache.cassandra.distributed.test.ClientNetworkStopStartTest.after(ClientNetworkStopStartTest.java:64)
{code}
since the after method attributes the failure to the proper test case, could
leverage this to avoid close shutting down in these types of tests?
> Make sure we don't throw any uncaught exceptions during in-jvm dtests
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-16101
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16101
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/java
> Reporter: Marcus Eriksson
> Assignee: Marcus Eriksson
> Priority: Normal
>
> We should assert that we don't throw any uncaught exceptions when running
> in-jvm dtests
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
