General Error Handling

[Michael_Melvin]

Good afternoon,

I am just wondering if there are any generic hooks or places to register an error handler in Camunda, rather than having to wrap every workflow as a subflow with an error boundary event.

The reason I am asking is that our tasks often call out to other microservices which may return an exception response. We may also throw an exception from our workflows, but of course this is noisy in the logs and does not always terminate the workflow. Clearly we can add boundary events to each of our tasks, but again, we are looking for a way to register a generic error handler for things like ResponseStatusExceptions that we can then terminate a flow without the logging noise that non-BpmnErrors seem to show.

On a side note, all of our delegates are our own subclasses of JavaDelegate as we have special handling for elevating permissions to make some of our outside microservice calls, so I don’t know if there is an interface or something that these could be decorated with that would allow us to then handle any exceptions arising form within the delegate without the need for wrapping the flow or adding an error boundary event on every service task.

Thanks in advance,

-mike

[pertsh.galstyan]

also interested in this question

[rohwerj]

Hi @Michael_Melvin and welcome back.
As @pertsh.galstyan also asked this question, I already answered here

General Error Handling in Camunda

Hi @pertsh.galstyan. Error boundary events are really more about “business errors”. By that I mean situations, that are not wanted but can occur in your business process. You shouldn’t model technical exceptions in your process definition. Also see here: Those exceptions will lead to incidents in your workflow (you can also configure a possible retry count). If you want some centralized handling of these incidents, you could write your own incident handler, that could perform needed task w…

Just a short recap. Error boundary events are really more about business errors, which you wand to handle in your process.
Technical exceptions should normally not be handled that way, but you can implement a custom incident handler, that could perform some tasks when an incident occurs.

[Rasim_Savas]

You can create an event subprocess in the root process; the event subprocess should have an error start event. Remember: the start error event does not have an error code; it must be set to ‘none.’ So, if you trigger a BPMN error anywhere and that error code does not exist in the process, the error start event (with a ‘none’ error code) will catch all BPMN errors.

error events not catching runtime error like a incident!

If you want to handle a specific BPMN error code, you can override this approach by connecting the relevant activity boundary to an error catch event. The thrown BPMN error will prioritize matching its own error code first.