nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Thomsen <mikerthom...@gmail.com>
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 {
    runner.run()
} catch (Throwable t) {
    error = t
} finally {
    assertNotNull(error)
    assertTrue(error.cause instanceof SomeException)
    assertTrue(error.cause.message.contains(msg))
}

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 <
james.srinivasan@gmail.com> 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 StandardProcessorTestRunner.run 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
>

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