search

camunda-community-hub / camunda-platform-7-camel

Community Extension to add Apache Camel support for Camunda Platform 7
Apache License 2.0
82 stars 57 forks source link

Issue 32: error handling #34

Closed stephanpelikan closed 6 years ago

stephanpelikan commented 6 years ago

see https://github.com/camunda/camunda-bpm-camel/issues/32

berndruecker commented 6 years ago

Wouldn't it be preferrable that some exception is thrown instead of raising a BpmError? If the BpmnError is NOT catched, than the process instance is terminated - which is typically not the best way to handle the situation. If some Java exception is not catched, it is normally handled. And you can catch Java Exception classes within Bpmn Error Boundary Events.

stephanpelikan commented 6 years ago

And you can catch Java Exception classes within Bpmn Error Boundary Events.

Oh, I didn't knew that. In https://docs.camunda.org/manual/7.7/examples/tutorials/error-handling/ this is not mentioned - or I can't find it. Which error has to be configured in BPMN? Or just leave the error boundary definition blank? Can you give me a hint? I would try it because it whould solve the problem without changing the code.

berndruecker commented 6 years ago

See https://docs.camunda.org/manual/7.7/reference/bpmn20/events/error-events/#defining-an-error - you can simply define a FQN of a Java class as error code. Feel free to also post a pull request in order to improve the tutorial you mention to include a hint :-) That would be totally awesome!

stephanpelikan commented 6 years ago

Using exception class names in BPMN processes is not that kind of abstraction for which BPMN is made for but the purpose blesses the tools ;-)