Add means to throw an error

[cdavernas]

What would you like to be added?

Add an action that allows throwing an error

Why is this needed?

Allows to define and throw workflow-specific errors, which is not possible as of now.

Coupled with the action's condition property, it could provide users a very powerfull - yet extremely simple - tool to perform flow and/or data validation logic.

What is your proposal?

Create a new throw or error action type, that allows users to do the following:

actions:
  - name: is-room-available
    functionRef:
      refName: check-if-room-is-available
      arguments:
        id: 123
    actionDataFilter:
      toStateData: .roomAvailable
  - name: throw-if-not-true
    condition: ${ .roomAvailable == false }
    errorRef:
      refName: room-not-available

If, as suggested in #770, we get rid of the top-level errors property, then it could instead look like:

actions:
  - name: is-room-available
    functionRef:
      refName: check-if-room-is-available
      arguments:
        id: 123
    actionDataFilter:
      toStateData: .roomAvailable
  - name: throw-if-not-true
    condition: ${ .roomAvailable == false }
    throw:
      type: https://fake.hotel.com/errors/room-not-available
      status: 409
      title: Room Not Available

[ricardozanini]

cc @fjtirado

[fjtirado]

Including an error object has been requested by community
see
https://kie.zulipchat.com/#narrow/stream/232676-kogito/topic/Exception.20Handling/near/360818735
and
https://kie.zulipchat.com/#narrow/stream/232676-kogito/topic/Serverless.20Workflow.20error.20events

[fjtirado]

So basically we nee a $WORKFLOW.lastError or something like that so users can do stuff like the one requested in those zulip discussion

[cdavernas]

@fjtirado So your suggestion is to include in the related PR a mechanism to "store" information about last thrown error?

What if, instead, we provide an array to store all errors that have previously occured, if need be? If you'd want to access the last, you could easily do something like '$WORKFLOW.errors | last'.

WDYT?

[fjtirado]

@cdavernas yes, they are basically asking how to know (from the state that is executed when the error happen) which was the error that causes the transition. This allow the same state handling different error types or extract info from the error itself

[fjtirado]

And yes, a stack of errors will do too

[cdavernas]

Do I have the go ahead to open a PR, then @ricardozanini @fjtirado @tsurdilo ?

[fjtirado]

Im going to play devils advocate, whats the diference between data condition on swith thats goes to an error branch and conditionally throw an error that goes to an error branch? ;)
Im not opposed to this, just a last time check so we wrote the rationale behind for posterity ;)