FlowException - corda

corda / net.corda.core.flows / FlowException

# FlowException

`open class FlowException : CordaException, IdentifiableException`

Exception which can be thrown by a FlowLogic at any point in its logic to unexpectedly bring it to a permanent end. The exception will propagate to all counterparty flows and will be thrown on their end the next time they wait on a FlowSession.receive or FlowSession.sendAndReceive. Any flow which no longer needs to do a receive, or has already ended, will not receive the exception (if this is required then have them wait for a confirmation message).

If the rethrown FlowException is uncaught in counterparty flows and propagation triggers then the exception is downgraded to an UnexpectedFlowEndException. This means only immediate counterparty flows will receive information about what the exception was.

FlowException (or a subclass) can be a valid expected response from a flow, particularly ones which act as a service. It is recommended a FlowLogic document the FlowException types it can throw.

### Constructors

#### <init> | `FlowException(message: String?, cause: Throwable?)` `FlowException(message: String?)` `FlowException(cause: Throwable?)` `FlowException()` Exception which can be thrown by a FlowLogic at any point in its logic to unexpectedly bring it to a permanent end. The exception will propagate to all counterparty flows and will be thrown on their end the next time they wait on a FlowSession.receive or FlowSession.sendAndReceive. Any flow which no longer needs to do a receive, or has already ended, will not receive the exception (if this is required then have them wait for a confirmation message). `FlowException(message: String?, cause: Throwable?, originalErrorId: Long? = null)`

### Properties

#### originalErrorId | the ID backing getErrorId. If null it will be set dynamically by the flow framework when the exception is handled. This ID is propagated to counterparty flows, even when the FlowException is downgraded to an UnexpectedFlowEndException. This is so the error conditions may be correlated later on. `var originalErrorId: Long?`

### Functions

#### getErrorId | `open fun getErrorId(): Long?`

### Inheritors

#### AttachmentResolutionException | The node asked a remote peer for the attachment identified by hash because it is a dependency of a transaction being resolved, but the remote peer would not provide it. `class AttachmentResolutionException : FlowException`
#### AttachmentResolutionException | `class AttachmentResolutionException : FlowException`
#### BrokenAttachmentException | A non-specific exception for the attachment identified by attachmentId. The context for this error is provided via the message and cause. `class BrokenAttachmentException : FlowException`
#### CashException | `class CashException : FlowException`
#### DoubleSpentInputs | `class DoubleSpentInputs : FlowException`
#### DuplicateOutputLabel | `class DuplicateOutputLabel : FlowException`
#### InsufficientBalanceException | Thrown if a request is made to spend an amount of a FungibleAsset but there aren't enough tokens in the vault. `class InsufficientBalanceException : FlowException`
#### MissingContractAttachments | A contract attachment was missing when trying to automatically attach all known contract attachments `class MissingContractAttachments : FlowException`
#### NotaryException | Exception thrown by the notary service if any issues are encountered while trying to commit a transaction. The underlying error specifies the cause of failure. `class NotaryException : FlowException`
#### StateReplacementException | `open class StateReplacementException : FlowException`
#### StatesNotAvailableException | `class StatesNotAvailableException : FlowException`
#### TransactionResolutionException | The node asked a remote peer for the transaction identified by hash because it is a dependency of a transaction being resolved, but the remote peer would not provide it. `open class TransactionResolutionException : FlowException`
#### TransactionVerificationException | Indicates that some aspect of the transaction named by txId violates the platform rules. The exact type of failure is expressed using a subclass. TransactionVerificationException is a FlowException and thus when thrown inside a flow, the details of the failure will be serialised, propagated to the peer and rethrown. `abstract class TransactionVerificationException : FlowException`
#### UnknownCalendar | `class UnknownCalendar : FlowException`
#### VaultQueryException | `class VaultQueryException : FlowException`