kamelet-binding : suport for error handling

[lburgazzoli]

We should support setting-up an error handler, like:

apiVersion: camel.apache.org/v1alpha1
kind: KameletBinding
metadata:
  name: telegram-text-source-to-kafka
spec:
  source:
    ref:
      kind: Kamelet
      apiVersion: camel.apache.org/v1alpha1
      name: telegram-text-source
    properties:
      botToken: the-token-here
  sink:
    ref: 
      kind: KafkaTopic
      apiVersion: kafka.strimzi.io/v1beta1
      name: my-topic
  error-handler: 
    ref:
      kind: Kamelet
      apiVersion: camel.apache.org/v1alpha1
      name: retry-handler
    properties:
      ...    

[lburgazzoli]

/cc @nicolaferraro

[squakez]

I am having a look at it

[heiko-braun]

Is there wat to distinguish types of errors that might trigger an error handler in the first place?
Thinking about something like this:

• Failure: External behavior is incorrect
• Fault: Discrepancy in code that causes a failure.
• Error: Human mistake that caused fault

Some examples that come to my mind to further illustrate this:

• Failure: Cannot connect to thirdparty system (i.e. transport level)
• Fault: Exception raised within the Camel DSL execution (i.e. syntax error)
• Error: Wrong credentials lead to authentication exceptions

If we could tell the difference between types of errors, we could supply more tailored error handling strategies (i.e. multiple error handlers)

Food for thought.

[squakez]

Not sure about the underlying details of Camel, but we may think of giving the user the possibility to chose what to do based on the specific exception caught. Maybe the same try-catch could work out of the box if used in the steps. However I think it defeats the concept of hiding the complexity behind the scene as the user must know the java exception type that may be thrown. We may consider come back to this as advanced feature in a future refinement.