There are three types of error events:
- Error end events in processes and services that throw errors. You can assign error codes and error data to errors that are thrown by the error end events.
- Error intermediate events in processes and services that catch errors
- Error start events in processes event sub-processes that catch errors
The most commom and practical approach which we use is a wrapper Human service to catch all service level errors and try to resume the service from the beginning of the service. The way it is done is that instead of linking your Human Services and System Services to the implementation there is one extra layer of wrapper Error Handler Service whenever we transition from a BPD to Service layer. You can do fancy things with it like showing stack trace only when environment is non-prod, addind a reassignment for Human Services to admin/support team, displaying the input variables as xml and allowing them to alter the input variables to make the service execute properly, obviously a retry is there. I personally believe that allowing support people to alter the xml data for BOs is a bad idea but for whatever reasons have seen it implemented in certain high profile projects.
And then obviously there are Exception handling toolkits like GEX which provide Service Exception Handler generic services and Process Exception handling services. You can get it from this link and looks like there is documentation also at this link https://hub.jazz.net/project/spcommunity/bpm-general-toolkits/overview#https://hub.jazz.net/git/spcommunity%252Fbpm-general-toolkits/list/master/GEX%2520-%2520General%2520Exception%2520Handler%2520Toolkit
Always keep in mind a catch all start error event can cause an infinite loop if the exception handling is automated and an error occurs in the exception handler itself.