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.sriniva...@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
>
