abstract 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.
enum class Direction
Whether the inputs or outputs list contains an encumbrance issue, see TransactionMissingEncumbranceException. |
class BrokenTransactionException : TransactionVerificationException |
|
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. |
|
class ConstraintPropagationRejection : TransactionVerificationException
This exception happens when a transaction was not built correctly. When a contract is not annotated with NoConstraintPropagation, then the platform ensures that the constraints of output states transition correctly from input states. |
|
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. |
|
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. |
|
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. |
|
class DuplicateAttachmentsRejection : TransactionVerificationException
Indicates that the same attachment has been added multiple times to a transaction. |
|
class InvalidAttachmentException : TransactionVerificationException |
|
class InvalidConstraintRejection : TransactionVerificationException
A constraint attached to a state was invalid, e.g. due to size limitations. |
|
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. |
|
class MissingNetworkParametersException : TransactionVerificationException
Thrown when the network parameters with hash: missingNetworkParametersHash is not available at this node. Usually all the parameters that are in the resolution chain for transaction with txId should be fetched from peer via FetchParametersFlow or from network map. |
|
class NotaryChangeInWrongTransactionType : TransactionVerificationException
An output state has a notary that doesn't match the transaction's notary field. It must! |
|
class OverlappingAttachmentsException : TransactionVerificationException
Thrown when multiple attachments provide the same file when building the AttachmentsClassloader for a transaction. |
|
class PackageOwnershipException : TransactionVerificationException
Thrown to indicate that a contract attachment is not signed by the network-wide package owner. Please note that the txId will always be SecureHash.zeroHash because package ownership is an error with a particular attachment, and because attachment classloaders are reused this is independent of any particular transaction. |
|
class TransactionContractConflictException : TransactionVerificationException
If a state is identified as belonging to a contract, either because the state class is defined as an inner class of the contract class or because the state class is annotated with BelongsToContract, then it must not be bundled in a TransactionState with a different contract. |
|
class TransactionDuplicateEncumbranceException : TransactionVerificationException
If two or more states refer to another state (as their encumbrance), then the bi-directionality property cannot be satisfied. |
|
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. |
|
class TransactionNetworkParameterOrderingException : TransactionVerificationException
If the network parameters associated with an input or reference state in a transaction are more recent than the network parameters of the new transaction itself. |
|
class TransactionNonMatchingEncumbranceException : TransactionVerificationException
An encumbered state should also be referenced as the encumbrance of another state in order to satisfy the bi-directionality property (a full cycle should be present). |
|
class TransactionNotaryMismatchEncumbranceException : TransactionVerificationException
All encumbered states should be assigned to the same notary. This is due to the fact that multi-notary transactions are not supported and thus two encumbered states with different notaries cannot be consumed in the same transaction. |
|
class TransactionRequiredContractUnspecifiedException : TransactionVerificationException |
|
class UnsupportedClassVersionError : TransactionVerificationException |
|
class UnsupportedHashTypeException : TransactionVerificationException |
|
class UntrustedAttachmentsException : CordaException
Thrown during classloading upon encountering an untrusted attachment (eg. not in the TRUSTED_UPLOADERS list) |
TransactionVerificationException(txId: SecureHash, message: String, cause: Throwable?)
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. |
val txId: SecureHash
the Merkle root hash (identifier) of the transaction that failed verification. |
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. |
open fun getErrorId(): Long? |
fun Any.contextLogger(): <ERROR CLASS>
When called from a companion object, returns the logger for the enclosing class. |
class BrokenTransactionException : TransactionVerificationException |
|
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. |
|
class ConstraintPropagationRejection : TransactionVerificationException
This exception happens when a transaction was not built correctly. When a contract is not annotated with NoConstraintPropagation, then the platform ensures that the constraints of output states transition correctly from input states. |
|
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. |
|
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. |
|
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. |
|
class DuplicateAttachmentsRejection : TransactionVerificationException
Indicates that the same attachment has been added multiple times to a transaction. |
|
class InvalidAttachmentException : TransactionVerificationException |
|
class InvalidConstraintRejection : TransactionVerificationException
A constraint attached to a state was invalid, e.g. due to size limitations. |
|
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. |
|
class MissingNetworkParametersException : TransactionVerificationException
Thrown when the network parameters with hash: missingNetworkParametersHash is not available at this node. Usually all the parameters that are in the resolution chain for transaction with txId should be fetched from peer via FetchParametersFlow or from network map. |
|
class NotaryChangeInWrongTransactionType : TransactionVerificationException
An output state has a notary that doesn't match the transaction's notary field. It must! |
|
class OverlappingAttachmentsException : TransactionVerificationException
Thrown when multiple attachments provide the same file when building the AttachmentsClassloader for a transaction. |
|
class PackageOwnershipException : TransactionVerificationException
Thrown to indicate that a contract attachment is not signed by the network-wide package owner. Please note that the txId will always be SecureHash.zeroHash because package ownership is an error with a particular attachment, and because attachment classloaders are reused this is independent of any particular transaction. |
|
class TransactionContractConflictException : TransactionVerificationException
If a state is identified as belonging to a contract, either because the state class is defined as an inner class of the contract class or because the state class is annotated with BelongsToContract, then it must not be bundled in a TransactionState with a different contract. |
|
class TransactionDuplicateEncumbranceException : TransactionVerificationException
If two or more states refer to another state (as their encumbrance), then the bi-directionality property cannot be satisfied. |
|
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. |
|
class TransactionNetworkParameterOrderingException : TransactionVerificationException
If the network parameters associated with an input or reference state in a transaction are more recent than the network parameters of the new transaction itself. |
|
class TransactionNonMatchingEncumbranceException : TransactionVerificationException
An encumbered state should also be referenced as the encumbrance of another state in order to satisfy the bi-directionality property (a full cycle should be present). |
|
class TransactionNotaryMismatchEncumbranceException : TransactionVerificationException
All encumbered states should be assigned to the same notary. This is due to the fact that multi-notary transactions are not supported and thus two encumbered states with different notaries cannot be consumed in the same transaction. |
|
class TransactionRequiredContractUnspecifiedException : TransactionVerificationException |
|
class UnsupportedClassVersionError : TransactionVerificationException |
|
class UnsupportedHashTypeException : TransactionVerificationException |