I agree - the notion of adding a "failure.reason" attribute is, in my opinion, an anti-pattern that should be avoided. Relationships are not a workaround but rather the preferred approach in this scenario - an attribute I would consider a workaround. This is due to the fact that not only is it brittle and complex to add processors that route on such things, but there's no reason at all to assume that from release to release (even bug fix/increment releases) that the Exception type or message will be the same, so the flow could stop working at any time after upgrading nifi. Relationships offer a well-defined way to explicitly indicate "these are the possible outcomes," similar IMO to Java Exception classes vs. throwing Strings in C.
> On Oct 25, 2018, at 9:47 AM, Bryan Bende <bbe...@gmail.com> wrote: > > I think processors should really have well defined relationships for > the error scenarios that need to be handled. Having the exception > message is ok for a human who wants to see it, but in order to do > anything with it in the flow you will have to have a bunch of > parsing/interpreting of the message with a bunch of routing > processors, which seems more brittle than just having the appropriate > relationships. > On Thu, Oct 25, 2018 at 1:36 AM Peter Wicks (pwicks) <pwi...@micron.com> > wrote: >> >> When a FlowFile is routed to failure, frequently there is no clear reason >> without looking into the actual error message. >> Some processors work around this by creating many different relationships, >> but even then frequently the generic Failure relationship also provides >> little guidance. >> >> I've seen a few cases recently where processors are including the exception >> message as an attribute on the FlowFile when routing to failure >> (ExecuteStreamCommand, new PR for ExecuteSQL). Should this be a standard >> pattern so that it's easier for users to route failures? >> >> --Peter
