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:
URISyntaxException and exceptions thrown by
FlowableException. If we use
<flowable:mapException> we cannot distinct if the root cause is because of an invalid URL or because of our custom
I would like to propose a new attribute for the
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
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
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