Class XrplResponse
Builds XrplResponse<T> from what a resolved request left in its promise.
Inheritance
Namespace: Xrpl.Client
Assembly: Xrpl.dll
Syntax
public static class XrplResponseMethods
| Edit this page View SourceFrom<T>(object)
Unpacks the pair the request manager put into the promise.
Declaration
public static XrplResponse<T> From<T>(object resolved)Parameters
| Type | Name | Description |
|---|---|---|
| object | resolved |
Returns
| Type | Description |
|---|---|
| XrplResponse<T> |
Type Parameters
| Name | Description |
|---|---|
| T |
Remarks
The manager knows the target type only as a System.Type, so it cannot build the generic response itself and carries both halves instead. This is where they come back together — inside the connection, so that no public method hands out an object the caller has no type to name.
Public because ResolvedResponse is: a caller working directly against
RequestManager — rather than through the client's own methods, which
already return XrplResponse<T> — gets a Promise that resolves to a
ResolvedResponse, and this is the supported way to turn that back into a
typed XrplResponse<T>.
From<T>(ResolvedResponse)
Unpacks a ResolvedResponse already in hand.
Declaration
public static XrplResponse<T> From<T>(ResolvedResponse resolved)Parameters
| Type | Name | Description |
|---|---|---|
| ResolvedResponse | resolved |
Returns
| Type | Description |
|---|---|
| XrplResponse<T> |
Type Parameters
| Name | Description |
|---|---|
| T |
Remarks
The object overload exists because Promise is typed Task<object> and cannot hand out
anything more specific. A caller that already has the ResolvedResponse —
having awaited the promise itself — should use this overload instead: the mismatch this
type carries the most (a Promise that resolved to something other than what the
request was created with) becomes a compile error here rather than the
XrplException the other overload has to throw at run time.