[
https://issues.apache.org/jira/browse/GEODE-953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15169489#comment-15169489
]
ASF subversion and git services commented on GEODE-953:
-------------------------------------------------------
Commit eb20383a50b9d447577da344046a138e9c21eff6 in incubator-geode's branch
refs/heads/feature/GEODE-953 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=eb20383 ]
Merge remote-tracking branch 'origin/develop' into feature/GEODE-953
> SerializableExternalResource and SerializableRuleChain should extend rather
> than borrow JUnit code
> --------------------------------------------------------------------------------------------------
>
> Key: GEODE-953
> URL: https://issues.apache.org/jira/browse/GEODE-953
> Project: Geode
> Issue Type: Bug
> Components: tests
> Reporter: Kirk Lund
> Assignee: Kirk Lund
>
> The override hooks that JUnit Rules provide allows a "before()" method to
> throw any Throwable (including checked exceptions), but does not allow an
> "after()" method to throw checked exceptions. See below:
> {noformat}
> protected void before() throws Throwable {
> protected void after() {
> {noformat}
> The currently committed versions of SerializableExternalResource and
> SerializableRuleChain borrow code from JUnit instead of extending JUnit
> classes to allow changing the after() to have a throws clause:
> {noformat}
> protected void after() {
> {noformat}
> If we choose to follow the JUnit best practice of having after() not perform
> any verifications (or otherwise be a very safe call that cannot throw checked
> exceptions), then we can change these classes to extend the JUnit classes
> instead of borrowing any code from JUnit.
> The Transaction and Off-Heap dunit tests should be changed to NOT perform any
> assertions during tearDown()/after(). There may be additional DUnit and JUnit
> tests that also need to change to bring them into line with the best practice
> Checked exceptions can also be wrapped in an Error or RuntimeException so
> this "limitation" could theoretically be worked around if necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
