corda / net.corda.core.contracts / TransactionVerificationException

TransactionVerificationException

sealed class TransactionVerificationException : FlowException

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.

Types

Direction

enum class Direction

Whether the inputs or outputs list contains an encumbrance issue, see TransactionMissingEncumbranceException.

Exceptions

ConflictingAttachmentsRejection

class ConflictingAttachmentsRejection : TransactionVerificationException

Indicates this transaction violates the "no overlap" rule: two attachments are trying to provide the same file path. Whereas Java classpaths would normally allow that with the first class taking precedence, this is not allowed in transactions for security reasons. This usually indicates that two separate apps share a dependency, in which case you could try 'shading the fat jars' to rename classes of dependencies. Or you could manually attach dependency JARs when building the transaction.

ContractConstraintRejection

class ContractConstraintRejection : TransactionVerificationException

The transaction attachment that contains the contractClass class didn't meet the constraints specified by the TransactionState.constraint object. This usually implies a version mismatch of some kind.

ContractCreationError

class ContractCreationError : TransactionVerificationException

A Contract class named by a state could not be constructed. Most likely you do not have a no-argument constructor, or the class doesn't subclass Contract.

ContractRejection

class ContractRejection : TransactionVerificationException

Indicates that one of the Contract.verify methods selected by the contract constraints and attachments rejected the transaction by throwing an exception.

MissingAttachmentRejection

class MissingAttachmentRejection : TransactionVerificationException

A state requested a contract class via its TransactionState.contract field that didn't appear in any attached JAR at all. This usually implies the attachments were forgotten or a version mismatch.

NotaryChangeInWrongTransactionType

class NotaryChangeInWrongTransactionType : TransactionVerificationException

An output state has a notary that doesn't match the transaction's notary field. It must!

TransactionMissingEncumbranceException

class TransactionMissingEncumbranceException : TransactionVerificationException

If a state is encumbered (the TransactionState.encumbrance field is set) then its encumbrance must be used as an input to any transaction that uses it. In this way states can be tied together in chains, thus composing logic. Note that encumbrances aren't fully supported by all aspects of the platform at this time so if you use them, you may find transactions created by the platform don't always respect the encumbrance rule.

Properties

txId

val txId: SecureHash

the Merkle root hash (identifier) of the transaction that failed verification.

Inherited Properties

originalErrorId

var originalErrorId: Long?

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.

Inherited Functions

getErrorId

open fun getErrorId(): Long?

Extension Functions

contextLogger

fun Any.contextLogger(): Logger

When called from a companion object, returns the logger for the enclosing class.

Inheritors

ConflictingAttachmentsRejection

class ConflictingAttachmentsRejection : TransactionVerificationException

Indicates this transaction violates the "no overlap" rule: two attachments are trying to provide the same file path. Whereas Java classpaths would normally allow that with the first class taking precedence, this is not allowed in transactions for security reasons. This usually indicates that two separate apps share a dependency, in which case you could try 'shading the fat jars' to rename classes of dependencies. Or you could manually attach dependency JARs when building the transaction.

ContractConstraintRejection

class ContractConstraintRejection : TransactionVerificationException

The transaction attachment that contains the contractClass class didn't meet the constraints specified by the TransactionState.constraint object. This usually implies a version mismatch of some kind.

ContractCreationError

class ContractCreationError : TransactionVerificationException

A Contract class named by a state could not be constructed. Most likely you do not have a no-argument constructor, or the class doesn't subclass Contract.

ContractRejection

class ContractRejection : TransactionVerificationException

Indicates that one of the Contract.verify methods selected by the contract constraints and attachments rejected the transaction by throwing an exception.

MissingAttachmentRejection

class MissingAttachmentRejection : TransactionVerificationException

A state requested a contract class via its TransactionState.contract field that didn't appear in any attached JAR at all. This usually implies the attachments were forgotten or a version mismatch.

NotaryChangeInWrongTransactionType

class NotaryChangeInWrongTransactionType : TransactionVerificationException

An output state has a notary that doesn't match the transaction's notary field. It must!

TransactionMissingEncumbranceException

class TransactionMissingEncumbranceException : TransactionVerificationException

If a state is encumbered (the TransactionState.encumbrance field is set) then its encumbrance must be used as an input to any transaction that uses it. In this way states can be tied together in chains, thus composing logic. Note that encumbrances aren't fully supported by all aspects of the platform at this time so if you use them, you may find transactions created by the platform don't always respect the encumbrance rule.