Document and implement best practices for error and exceptions handling by applications. [1] is a thread starting the conversation and the first thoughts are also below.

[1] https://lists.opendaylight.org/pipermail/netvirt-dev/2018-June/007027.html

In my mind, handling exceptions serves two main purposes:

• prevent errors from cascading;
• provide appropriate diagnostics for (a) the end user and (b)
  technical support (whatever form that may take).

The first of these means that we shouldn’t swallow exceptions: if an
error occurs, we need to propagate it back up to whatever level makes
sense, cancelling transactions as we go. This meshes quite nicely with
our existing recommendation for transaction handling, at least as a
goal, which is, as far as possible, to open a transaction (or however
many transactions are necessary) at the highest possible level, and use
that for all subsequent method calls. There are a couple places where
I’ve refactored code to do that, I’ll find them and follow up. The
basic idea is in most cases to open a ReadWriteTransaction in listeners
or RPC handlers, and pass it to all methods being called.

The second of these typically means that we need to log something
somewhere. There’s a general rule of error handling which says that
whenever you catch an exception, you should either log it or rethrow
it, but not both; that usually means that you log at the top level, not
below, which can mean information is lost. In typical ODL cases it
probably means we should log in the “first chance” exception handler
(i.e. closest to where we notice the exception), and again at the top
level. The first log there addresses the tech support diagnostic use
case, the second addresses the end-user information use case.