Exception boundary event not getting triggered



need some pointers on an issue that we have where a boundary event attached to a service task not getting fired. Below is the property section of the boundary event.

Here is the delegate class that is attached to a service class with an attached boundary event.

public class ABC implements JavaDelegate,Constants {

  public synchronized void execute(DelegateExecution execution) throws Exception {

			Call a Function from class XYZ with some params

}catch (Exception e) {
LOGGER.info(“exception occured” + e);
throw e;


public class XYZ extends Service implements Constants{

public Integer fun1(String formName,List Map1,Integer Id,String str) throws Exception {

// consume a service to create a request using org.apache.cxf.endpoint.Client  from the stack it looks like there is an exception here which should bubble up and be caught at the top level.



So when the issue occurs we see that there is a callstack in the logs with “Caused by: java.net.SocketTimeoutException: Read timed out” and the process gets killed. However the behavior we need is that it logs the error and continues to execute with next steps.

Any pointers is much appreciated.



You may want to catch the java exception and re-throw it as BpmnError for an error boundary event to take effect.

This [1] pattern thread may be of interest…



[1] Pattern - Fail Faster, Best Efforts


HI Rob,

in the code that I shared, there already is a try catch and its being thrown as a java exception. my question was why the boundary wouldn’t pick it and take the exception route?



Hi Sandeep,

you must throw a BpmnError. See here [1] for more detail



[1] https://docs.camunda.org/manual/7.8/user-guide/process-engine/delegation-code/#throw-bpmn-errors-from-delegation-code


Thanks Rob. I will try to write some sample code to test this.

Does this mean, we will have to use BPMNError all the time. Currently the exception handling is set up the way I described above. All seem to work except for the activity where its failing for external service (I see that the boundary event gets triggered for other tasks, but it’s not making any calls to external services).



Hi Rob,

I was trying to reproduce this issue and in my repro code the external exceptions are getting trapped by using java.lang.Throwable (not as BPMNError). I will try few different exceptions and let you know. is there any debugging setting that I can enable to get some more information (to enable more logging so we can check what is going on)?



I have the same problem: The exception boundary event is not triggered.

Is this true what @Webcyberrob says: It must be a BpmnError and not an other java exception?
Didn’t find this limitation in documentation. And if yes, why? Writing code wrapping every exception is really stupid.

Or is it perhaps because i configured a retry for this activity?

I haven’t configured an error ref for this boundary, so it should catch all.



this thread may be of interest…

Key takeways from my perspective is these kinds of exceptions are ultimately technical errors. The incident system tends to treat these technical errors for operator intervention via the console. If the treatment of the error is a business treatment, then the BPMN Error event makes this explicit.

However your code needs to differentiate the two treatments and thus potentially wrap a technical exception into a business exception.

There may be smarter ways to commoditize this - parse listerners to inject wrapper code, possibly an engine plugin approach…




After wrapping all errors to BpmnErrors I now found out that the specified retry is ignored then.
Sorry, but this is shit. Has nobody thought about real use cases when defined how the camunda engine works? Seams to be a collection of random decisions without any sense. I really don’t want to implement each simple default case myself as a bpmn process at each place.

I was waiting for many years to try camunda in a real project and really regret it. It is much more effort to make it work somehow and finally I have to implement everything myself because nothing is well-thought-out.


@bmaehr you seem to be trying to mix concepts together and getting annoyed when opposite ends of the spectrum tools are conflicting when mixed together.

BPMN errors are Business Errors. They are part of the spec. They dont get triggered after 3 attempts, they get triggered as soon as the BPMN error is thrown. “Sign a Document… Oh! the signature is invalid, throw a bpmn error”

Incidents are for non-bpmn-errors. It is attempting multiple times because its a system error that could self-resolve.

If you need extra special handling take a look at something like this: https://github.com/StephenOTT/camunda-incident-handler-nashorn-js. You can write a Custom Incident Handler to do whatever actions you need when a incident occurs.

If you need retry’s on your bpmn error, then use a looping logic on the gateway. or add a circuit breaker / loop counter to try N times and if error count reaches 3 then throw a BPMN error.