Class TransactionFailedException

A transaction was submitted and did not succeed.

Inheritance

object

Exception

RippleException

TransactionFailedException

Namespace: Xrpl.Client.Exceptions

Assembly: Xrpl.dll

Syntax

public class TransactionFailedException : RippleException

Remarks

The result code decides what a caller should do next, and the classes differ completely: tem means the request is malformed and must be fixed before it is sent again, tec means it was applied to a ledger and the fee was taken, ter means it may work later. Telling them apart used to mean reading the exception's message, which works until the first transaction whose message contains the substring somewhere else.

This derives from RippleException and keeps the message it always had, so a catch (RippleException) and anything matching on the text carry on unchanged. What is new is beside the message rather than inside it.

Constructors

TransactionFailedException(string, string, string, TransactionSummary)

Declaration

public TransactionFailedException(string message, string engineResult, string hash, TransactionSummary result = null)

Parameters

Type	Name	Description
string	message	The message this exception has always carried, unchanged.
string	engineResult	The node's result code.
string	hash	The transaction's hash.
TransactionSummary	result	The validated transaction, or null if there is none.

Properties

EngineResult

The result code, as the node reported it - tecINSUFFICIENT_PAYMENT, temBAD_FEE and so on.

Declaration

public string EngineResult { get; }

Property Value

Type	Description
string

Hash

The transaction's hash.

Declaration

public string Hash { get; }

Property Value

Type	Description
string

Remarks

Worth having even when the transaction never reached a ledger, but it is the ReachedLedger case where it matters: there is something to look up, and showing it is usually the first thing anyone wants to do after a refusal.

ReachedLedger

Whether the transaction was applied to a ledger - the fee taken, the transaction there to be looked up.

Declaration

public bool ReachedLedger { get; }

Property Value

Type	Description
bool

Remarks

The difference is not a detail: applied means the fee is gone and there is something to show, while a refusal before that costs nothing and leaves nothing. The two arrive as the same kind of failure and are not the same event.

Read from the result code rather than from whether Result happens to be here, because the same failure can be reported at two moments: once the transaction is validated, with its metadata, or earlier from the node's provisional answer, when only the code and the hash exist yet. A tec means applied either way, and which of the two moments won a race is not something a caller should have to think about.

So Result can be null while this is true. The hash is present in both cases, and the hash is what an explorer needs.

Result

The validated transaction, metadata included - or null when there is none to hand back yet.

Declaration

public TransactionSummary Result { get; }

Property Value

Type	Description
TransactionSummary

Remarks

Absent for a failure the node refused before a ledger, which is what one would expect, and absent as well when a tec was reported from the provisional answer before the ledger closed. Use ReachedLedger to tell whether the fee was taken; Hash is there in every case.

Extension Methods

XrplErrorClassifier.Classify(Exception)