Extending mapException to allow filtering based on rootCause

Flowable Engine throws FlowableExceptions in almost every case, and sometimes it is difficult to write proper <flowable:mapException> tags to cover them since we can’t know the root cause if we want to handle them differently.

For an example:

org.flowable.http.HttpActivityExecutor wraps ClientProtocolException, IOException, URISyntaxException and exceptions thrown by httpRequestHandler or httpResponseHandler into FlowableException. If we use <flowable:mapException> we cannot distinct if the root cause is because of an invalid URL or because of our custom HttpRequestHandler.

I would like to propose a new attribute for the <flowable:mapException> tag, rootCause which would allow to map exceptions based on the root cause of the exception.

For an example:

<flowable:mapException errorCode="myErrorCode1" rootCause="java.net.URISyntaxException">org.flowable.SomeException</flowable:mapException> which would handle all org.flowable.SomeException caused by java.net.URISyntaxException.

Does this sound like wrong design or a good feature? If it sounds useful, I would happily submit a PR with an example.

There seems to be support for that already, see https://github.com/flowable/flowable-engine/blob/master/modules/flowable-engine/src/main/java/org/flowable/engine/impl/bpmn/helper/ErrorPropagation.java#L343 : from that code, it looks like if the boolean flag ‘andChildren’ is added and set to true, the exception should match for subclasses too. I don’t find tests for this though, so not sure if it works properly.

I might be mistaken, but that seems like the opposite of this? I agree it is implemented right, but it is a different feature.

<flowable:mapException errorCode="myErrorCode1" andChildren="true">org.flowable.SomeException</flowable:mapException>

Would catch all org.flowable.SomeException and it’s subclasses. That seems totally fair.

<flowable:mapException errorCode="myErrorCode1" rootCause="java.net.URISyntaxException">org.flowable.SomeException</flowable:mapException>

Would however catch org.flowable.SomeException ONLY if it was caused by a java.net.URISyntaxException, something like throw new SomeException((java.net.URISyntaxException) e)

The difference here is that I would like to handle FlowableException only if it was caused by a specific exception. Flowable engine wraps all exceptions and there is currently no way (that I know of) on how to handle different causes through BPMN flow using flowable:mapException.

Hope that clarifies my intention a little.

Ok, i see your point. I understood it indeed backwards. Thanks for the proper clarification :-).

Your idea makes indeed sense and would be good to have.
Alternatively, I was thinking that having a specific (new) type of exception would also solve this maybe better? So instead of throwing FlowableException, have specific FlowableXyzException instead. Wdyt?

Flowable documentation said that they wouldn’t like a big exception hierarchy and would like to keep exceptions down to as few as possible.

More about that here: https://flowable.org/docs/userguide/index.html#_exception_strategy

Created a new PR here:https://github.com/flowable/flowable-engine/pull/1162

Any opinions on this?

PR merged, so all good :slight_smile: