nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Thomsen <>
Subject Re: Error handling in @OnScheduled
Date Thu, 23 Aug 2018 14:38:33 GMT
For unit tests, if you're doing this to catch a failure scenario, you
should be able to wrap the failing call in something like this:

final def msg = "Lorem ipsum..."
def error = null
try {
} catch (Throwable t) {
    error = t
} finally {
    assertTrue(error.cause instanceof SomeException)

Obviously play around with the finally block, but I've had success with
that pattern.

On Thu, Aug 23, 2018 at 10:19 AM James Srinivasan <> wrote:

> What is the best way to handle exceptions which might be thrown in my
> @OnScheduled method? Right now, I'm logging and propagating the
> exception which has the desired behaviour in NiFi (bulletin in GUI and
> processor cannot be started) but when trying to add a unit test, the
> (expected) exception is caught in and
> failure asserted.
> My actual @OnScheduled method builds a non-trivial object based on the
> Processor's params - maybe I should be building that any time any of
> the params change instead?
> Many thanks,
> James

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message