[
https://issues.apache.org/jira/browse/CASSANDRA-16101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194494#comment-17194494
]
David Capwell commented on CASSANDRA-16101:
-------------------------------------------
bq. I did this first, but then thought we could just catch any exceptions and
ignore them if expected, do you have an example where this would not be enough?
I was thinking about the repair tests which trigger failures by design. Since
repair uses JMXEnabledThreadPoolExecutor any thrown exception will be handled
in org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor#handleOrLog
which calls
{code:java}
Thread.getDefaultUncaughtExceptionHandler().uncaughtException(Thread.currentThread(),
t);
{code}
so they should cause that list to be non-empty.
bq. thought we could just catch any exceptions and ignore them if expected
I may be thinking about this differently than you, but not sure how the test
can catch and ignore them. The one thing that seems possible is if I try to
remove them from the list before the test ends (it is copy-on-write so I can
try to remove). In the repair tests we reuse the cluster, so would need to
wrap every test with a try/finally to attempt to cleanup expected exceptions.
> 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
