Class AbstractSuccessAbruptCompletionException

java.lang.Object
java.lang.Throwable
java.lang.Exception
de.xima.fc.exceptions.AbstractXfcException
de.xima.fc.exceptions.WorkflowProcessingException
de.xima.fc.exceptions.AbstractAbruptCompletionException
de.xima.fc.exceptions.AbstractSuccessAbruptCompletionException
All Implemented Interfaces:
de.xima.cmn.i18n.ILocalizedMessageProvider, IXfcException, IBaseCompletionResult, ISuccessResultData, Serializable
Direct Known Subclasses:
NodeReturnedException, NodeTransferredControlException
public abstract class AbstractSuccessAbruptCompletionException extends AbstractAbruptCompletionException implements ISuccessResultData
Used by a node to indicate that the node completed abruptly by issuing a break or continue statement that jumps out of the current loop iteration.
Since:
8.2.0
Author:
XIMA MEDIA GmbH
See Also:

  • Constructor Details

    • AbstractSuccessAbruptCompletionException

      protected AbstractSuccessAbruptCompletionException(AbstractSuccessAbruptCompletionException.Builder<?> builder)
      Creates a new exception that should be thrown when a node wishes to complete abruptly in a successful manner.
      Parameters:
      builder - Builder with the data to set.

  • Method Details

    • getSoftErrors

      public final List<NodeSoftErrorException> getSoftErrors()
      Description copied from interface: ISuccessResultData
      Business logic might need to distinguish between hard errors and soft errors. A hard error is an exception that results in the workflow failing when not caught by an error handler. These are for example technical errors such as a missing database connection, or when a file cannot be read form the file system due to missing permissions.

      Soft errors are similar to warnings in that not all of the the business logic could be performed or that some the business logic had to be skipped. In contrast with hard errors, however, the node itself still completes normally and does not cause the workflow to fail. This method can be used to check if any soft errors occurred.

      Soft errors are similar to hard errors in that both provide an error code, an error message, as well as custom additional data.

      Common examples of soft errors include missing files from optional upload form elements, or a 4xx HTTP return code. However, the exact definition of what constitutes a soft error must be decided on a case-by-case basis by each individual node implementation. This method is meant to be a uniform interface for nodes to provide information about soft errors. This method can also be used to check whether a node was "successful", by checking whether the list of soft errors is empty. Implementations are encouraged to provide more details about their completion status via ISuccessResultData.getSuccessValue().

      Soft errors are purely informational. Workflow execution is not affected in any way by whether or not soft error occurred. The node still either completes normally or returns, and the next node or trigger is processed as if no soft errors were present.

      @implNote This interface provides a default implementation that returns an empty list for backwards compatibility so as not to break existing implementation. However, all existing implementations are strongly advised to override and implement this method. The default implementation may be removed at some point.

      Specified by:
      getSoftErrors in interface ISuccessResultData
      Returns:
      A list of soft errors that did occur during the execution of the workflow node.

    • getSuccessValue

      public final Object getSuccessValue()
      Specified by:
      getSuccessValue in interface ISuccessResultData
      Returns:
      The value that is returned when node completed normally. Must conform to the IExecutionResultDescriptor.getSuccessValueDescriptor(IValueDescriptorFactory) IExecutionResultDescriptor#getSuccessValueDescriptor.