Is this expected trap behaviour when failing a cascading flow fast?

[archcosmo]

Hi @cwensel,

I have a case in my Cascading flow where I want to fail the entire job at a certain step, and am doing so by throwing a RuntimeException.

This works in most cases, but I have noticed that when I have a trap defined on an earlier step in the pipe, the RuntimeException I am throwing is rethrown and caught by the trap handler at an earlier point in the pipe. This is actually resulting in a more obscure error in my job output, but my concern is that there could be cases where the trap handler actually writes unexpectedly to my sink location.

Is this expected trap behaviour, and if so is there a way I am meant to be failing a job when there is a trap defined on an earlier pipe step?

[cwensel]

This should be well documented:

• http://docs.cascading.org/cascading/3.3/userguide/ch15-advanced.html#failure-traps

It's been a while, but you should be able to rename the branch so there isn't a trap bound to it, and any exceptions will carry on.

There is also a StopDataNotificationException that bypasses the traps, but I don't think it was fully implemented to support Hadoop.