reef-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Dudoladov (JIRA)" <>
Subject [jira] [Commented] (REEF-864) Make exception handling consistent
Date Thu, 17 Dec 2015 14:59:46 GMT


Sergey Dudoladov commented on REEF-864:

The early  draft of exception handling policy in REEF:

h5. Preliminaries

* Bloch, 63 means "Item 63 in Effective Java";  Yuan et al means Sections 4.1 and 5 in the
[OSDI paper|]

* For custom checks, we can open a pull request at [sevntu.checkstyle |]
and wait until someone implements them.

* Checks from  sevntu sometimes duplicate core checkstyle checks. In this list I preferred
the core checkstyle.

* Everything below is written forJava. Feel free to add C# issues.

h5. Throwing exceptions

* Each exception must have a non-empty message. The message must contain enough info to determine
why the exception occurred (examples in Bloch, 63). How to enforce:  code review. We can also
consider  a custom check that prohibits (a) using Exception no-args constructors  (b) passing
empty strings literals to Exception constructors.

* Exceptions thrown within try/catch  blocks  must preserve the original exception to keep
the stack trace. How to enforce: [AvoidHidingCauseExceptionCheck|].
The [{{getRootCause()}} |]from
Apache Commons enables retrieving the initial exception.

* Log and (re)throw. Doing both at the same time is sometimes [considered an antipattern|] ([relevant check|
]). So we need to discuss if REEF really needs this. How to enforce: a custom check.

* Forbid throwing general exceptions: {{Error}}, {{RuntimeException}}, {{Throwable}}, {{Exception}}.
How to enforce: partially covered by [IllegalThrows |].

* Forbid non-final fields in user-defined exception classes. How to enforce: [MutableException|]

* Forbid throwing [anonymous exceptions |].
How to enforce: [ForbidThrowAnonymousExceptions |]

h5.  Handling exceptions

The main idea is to prevent ignoring exceptions (Bloch, 65); some rules here impose stronger
conditions than "Effective Java" does .

* Forbid catching general exceptions: {{Error}}, {{RuntimeException}}, {{Throwable}}, {{Exception}}.
How to enforce: [IllegalCatch|].

* Forbid  empty catch blocks. How to enforce: [EmptyCatchBlock |
]. This check also enables [documenting expected exceptions |].

* Forbid  catch blocks that only rethrow the original exception. How to enforce: [UselessSingleCatchCheck

* Forbid  catch blocks that  contain only log statements. How to enforce: a custom check.
Source: Yuan et al.

* Forbid  catch blocks that  contain comments with tags {{TODO}}, {{FIXME}}, {{FIX}}, {{[XXX|]}},
i.e. are knowingly incomplete.  How to enforce: a custom check. Source: Yuan et al.

* [Forbid  {{return}} in finally blocks|].
 How to enforce: [ForbidReturnInFinallyBlockCheck|].

h5. Specific Exceptions

* {{NotImplementedException}}  and {{UnsupportedOperationException}} must (a) include a text
description of what prevents implementation  and (b) provide a {{TODO}} with the corresponding
JIRA issue. How to enforce: code review.

> Make exception handling consistent
> ----------------------------------
>                 Key: REEF-864
>                 URL:
>             Project: REEF
>          Issue Type: Improvement
>          Components: Build infrastructure, Documentation
>            Reporter: Sergey Dudoladov
>            Assignee: Sergey Dudoladov
> The recent [OSDI paper |]
suggest that many failures in distributed systems arise from 3 trivial mistake in exception
> 1) the handler is empty
> 2) the handler silently aborts
> 3) the handler contains phrases like “TODO” and “FIXME”, i.e. is knowingly incomplete
> The authors propose [their own checker|] for these cases,
but we can try to enforce any of these rules via checkstyle, for example.

This message was sent by Atlassian JIRA

View raw message