nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Payne <marka...@hotmail.com>
Subject Re: Error handling in @OnScheduled
Date Thu, 23 Aug 2018 14:51:39 GMT
James,

If you are expecting the method to throw an Exception and want to verify that, you should
just call the method directly from your unit test and catch the Exception there. The TestRunner
expects to run the full lifecycle of the Processor.

Thanks
-Mark


> On Aug 23, 2018, at 10:49 AM, James Srinivasan <james.srinivasan@gmail.com> wrote:
> 
> I tried that, but the problem is the exception is caught and the test
> fails due to this:
> 
> try {
>  ReflectionUtils.invokeMethodsWithAnnotation(OnScheduled.class,
> processor, context);
> } catch (final Exception e) {
>  e.printStackTrace();
>  Assert.fail("Could not invoke methods annotated with @OnScheduled
> annotation due to: " + e);
> }
> 
> https://github.com/apache/nifi/blob/master/nifi-mock/src/main/java/org/apache/nifi/util/StandardProcessorTestRunner.java#L181
> On Thu, 23 Aug 2018 at 15:41, Mike Thomsen <mikerthomsen@gmail.com> wrote:
>> 
>> 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
View raw message