Support catch-all Error And Escalation Events

[sombrek]

Proposed Changes

Closes #184

Error and escalation throw events with reference objects (e.g. errorRef) now match catch events without reference object (catch-all events).

When multiple events in a scope match, they are checked in the following order: event sub process with same reference, event sub process catch-all, boundary event with same reference, boundary catch-all.

Demo

[barmac]

I am looking into this right now. Thanks for the PR and sorry for a delay in review.

[barmac]

Great contribution. Let's merge it as is. Thank you!

[barmac]

Published in v0.35.0

[nikku]

I have a hard time to understand what this does. Do you remember @sombrek? Why is the boundary event check necessary, which scenarios do we cover here?

[sombrek]

@nikku Yes, I remember.

There are now two types of handlers: Catch-all handlers and specific handlers that have an error/escalation reference.

Scenario: When an error/escalation occurs, you have to find the nearest matching event handler. Handlers are checked in this order: specific event sub process, catch-all event sub process, specific boundary event, catch-all boundary event. If there's no match, repeat on parent scope (at least for escalation).

bpmn-js-token-simulation/lib/simulator/Simulator.js

Lines 225 to 233 in 7c7415b

	const referenceSubscriptions = filterSet(
	matchingSubscriptions, subscription => refsMatch(event, subscription.event)
	);
	if (matchingSubscriptions.every(subscription => subscription.event.boundary)
	&& referenceSubscriptions.some(subscription => subscription.event.boundary)
	|| referenceSubscriptions.some(subscription => !subscription.event.boundary)) {
	matchingSubscriptions = referenceSubscriptions;
	}

The check determines whether there's a specific handler: Starting with the second part. If there's a specific event sub process, use that. Otherwise, if there are only boundary events and at least one of them has a specific reference, use that. If that check fails, there are only catch-all handlers.

[nikku]

Thanks for the details. I think I'll need to further debug this "in action" to see how it works, and leave a comment for future reference.