+1 

What I like is that it allows from some kind of type safety into the error 
management beyond trying to parse error strings.

> On 05 Apr 2016, at 03:48, Michael Park <[email protected]> wrote:
> 
> Contrary to standard C++ practices, Mesos uses return values as the
> mechanism
> for error handling rather than exceptions.
> 
> This proposal is simply an evolution of the current mechanism we have in
> Mesos today.
> This direction is consistent with the designs made in Rust, which uses
> return values as
> the error handling mechanism at the language level.
> 
> The first step is to add an additional template parameter to class template
> *Try*, to get *Try<T, E>*.
> 
> The proposed design defaults* E *to *Error*, and requires that *E* be, or
> is inherited from *Error*.
> The return type of *error()* is *const std::string&* if *E == Error* and
> *const E&* otherwise,
> for backwards-compatibility reasons.
> 
> So in the end, *Try<T>* behaves exactly as before.
> 
> The work is being tracked in MESOS-5107
> <https://issues.apache.org/jira/browse/MESOS-5107>, and i've written a
> quick design doc
> <https://docs.google.com/document/d/1tG21sD-ZX64FHAKJwhEPk6JkgsBIv12AmA1Y3J0kCYY/edit#>
> capturing
> some of the preliminary thoughts on this topic, and a proposal for an
> immediate use case
> for the Windows work.
> 
> If you're interested in how Rust deals with error handling, check out
> https://doc.rust-lang.org/book/error-handling.html. Our *Option* is their
> *Option*,
> our *Try* is their *Result*, and they don't have our *Result*.
> 
> I'm going to be pushing the changes proposed shortly, but the changes are
> small and
> does not require a large sweeping changes or anything like that.
> So please reach out to me with your concerns and complaints and I will be
> sure to address them.
> 
> Thanks,
> 
> MPark

Reply via email to