[ https://issues.apache.org/jira/browse/SLING-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16708664#comment-16708664 ]
Valentin Olteanu edited comment on SLING-8114 at 12/4/18 1:05 PM: ------------------------------------------------------------------ [~petitbear68], I (partially) like the DSL provided by {{awaitility}}, but I wouldn't include it in {{sling.testing.clients}} because it brings too many dependencies (junit, hamcrest), which we kept away on purpose and moved the related classes to {{sling.testing.rules}}. Including it would also mean exposing all its classes as part of our API, so we would be susceptible to breaking changes introduced by new versions. But we _could_ introduce a similar DSL to {{Polling}} :D Back to the original problem, [catching Throwable is a bad practice|https://stackoverflow.com/questions/6083248/is-it-a-bad-practice-to-catch-throwable], especially for {{Error}} s. So I wouldn't even add this, but change the test code to throw another exception (why not {{ClientException}} ?). I suppose we need to better document this in the Polling. Note: I just realised we are already too greedy with catching {{Exception}} and we should re-throw {{InterruptedException}} - created SLING-8160 for this. was (Author: volteanu): [~petitbear68], I (partially) like the DSL provided by {{awaitility}}, but I wouldn't include it in {{sling.testing.clients}} because it brings too many dependencies (junit, hamcrest), which we kept away on purpose and moved the related classes to {{sling.testing.rules}}. Including it would also mean exposing all its classes as part of our API, so we would be susceptible to breaking changes introduced by new versions. But we _could_ introduce a similar DSL to {{Polling}} :D Back to the original problem, [catching Throwable is a bad practice|https://stackoverflow.com/questions/6083248/is-it-a-bad-practice-to-catch-throwable], especially for {{Error}}s. So I wouldn't even add this, but change the test code to throw another exception (why not {{ClientException}} ?). I suppose we need to better document this in the Polling. Note: I just realised we are already too greedy with catching {{Exception}} and we should re-throw {{InterruptedException}} - created SLING-8160 for this. > Allow to do polling of code failing on asserts > ---------------------------------------------- > > Key: SLING-8114 > URL: https://issues.apache.org/jira/browse/SLING-8114 > Project: Sling > Issue Type: Improvement > Components: Apache Sling Testing Clients > Affects Versions: Apache Sling Testing Clients 1.2.0 > Reporter: Thierry Ygé > Priority: Major > > Currently if you polling check uses assertions , it will not be retried, this > is due to this line > [https://github.com/apache/sling-org-apache-sling-testing-clients/blob/master/src/main/java/org/apache/sling/testing/clients/util/poller/Polling.java#L118] > Which is only catching Exceptions while failing Assertions are an error kind > (AssertionError). > It would be nice to handle it so that code wouldn't have to "transform" it to > exception. > To reproduce simply use assertion in your polling check and let it fail if a > counter is lower than a value. make the polling retries so that at the next > retry counter it should pass. > > {quote}int count = 0; > new Polling(() -> { count++; Assert.assertTrue(count == 2); return true; > } > ).poll(2000, 500); > {quote} > Observation: it exist the poll directly as the assert fail already. > Expected: It should have polled until the check pass here. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)