[
https://issues.apache.org/jira/browse/MESOS-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16488205#comment-16488205
]
Chun-Hung Hsiao commented on MESOS-8925:
----------------------------------------
The following related patches are submitted:
{noformat}
commit d7a1fe47e06944dcb50d93b697f8cfcf743bb1a5
Author: Chun-Hung Hsiao <[email protected]>
Date: Thu May 17 12:25:12 2018 -0700
Overloaded `stringify` for `Error`s to reduce overheads.
Review: https://reviews.apache.org/r/67190{noformat}
{noformat}
commit f8829f87e7220eccbdcf2dec6f5e4a63af0a5a7b
Author: Chun-Hung Hsiao <[email protected]>
Date: Thu May 17 12:13:10 2018 -0700
Supported custom error types for the `Future(Try<...>)` constructor.
Review: https://reviews.apache.org/r/67191{noformat}
> Support flattening from Try with custom errors into Future
> ----------------------------------------------------------
>
> Key: MESOS-8925
> URL: https://issues.apache.org/jira/browse/MESOS-8925
> Project: Mesos
> Issue Type: Improvement
> Components: libprocess
> Reporter: Benjamin Bannier
> Priority: Major
>
> {{Try<T, E>}} is parameterized on the type of the error and defaults to the
> pretty {{std::string}}-like {{Error}}. Custom error types allow propagating
> domain specific failure information and can e.g., be used to implement more
> granular error handling.
> While we currently support flattening a {{Try<T, Error>}} into a {{Future}},
> this is e.g., not possible for error types not derived from {{Error}}. This
> lack of genericness hampers effective use of composition of functions
> producing a {{Try}} with non-{{Error}} failures with asynchronous
> computations since users might e.g., need to create {{Future<Try<T,
> CustomError>>}} values to capture the full information.
> From the implementation side this lack of support seems to mostly hinge on
> {{Failure}} being non-generic and very {{Error}}-like (which in turn is very
> {{std::string}}-like).
> We should consider either
> # making {{Failure}} a template accepting generic error types ({{Future}}
> would be parameterized on the same error type as well then), or
> # supporting construction of {{Failure}} from generic error types, but only
> requiring that the type can be stringified.
> While the former approach would add the same extensibility {{Try}} already
> provides to {{Future}}, the latter would at least allow non-{{Error}} {{Try}}
> values to propagate into {{Future}} values.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
