You’re throwing the BPMN error as part of the output parameters, thats not quite correct, at that point the task has left the scope by which it would be caught by the boundary event.
Does that mean if we have service tasks and want to catch any script errors we cannot use output parameters at all??
also for a avg use case if there are 5-10 service task do we need an equivalent number of scripts tasks/decision gateways?
Technical errors can still be caught by the engine but if you throw an event like a BPMN Error event form the script it won’t be caught by the boundary event - because it’s no longer in scope - if you wanted you could still catch the error in a sub process boundary event or using an event sub process.
I’m not really sure what you mean my this - the answer is probably no. There are always a lot of ways to model these scenarios and depending on the symbols you use you could make it look quite easy or quite complex/
Throw the error as part of the task - i dont know why you’re using the output parameter to throw the error, it’s a little unusual. just throw it from the script itself
We do lot of processing on response and its used heavily. Whatever is possible we are throwing from task. Above is just a sample bpmn to verify the functionality.
Also we do this in serviceTask mainly not script task