Re: Typed Error Handling in Mesos

Usually you would fix the left type and only keep the right type variable. `then` looks like it’s a combination of what in other languages / libraries may be two separate methods called `map` and `flatMap` (or `fmap` and `bind` in Haskell). Here however, we are only interested in the `flatMap` c

Re: Typed Error Handling in Mesos

Long overdue, thanks Michael! Have you considered how composition will work with typed errors? I recall in the past when we looked into this, Future chaining was interesting: f1 = []() -> Future { ... }; f2 = []() -> Future { ... }; f3 = []() -> Future { ... }; f1().then(f2).then(f3) // what doe

Re: Typed Error Handling in Mesos

+1 Another use case: https://github.com/mesosphere/marathon/commit/d616c05619753e398e882fa8d80e35e137775b30 https://issues.apache.org/jira/browse/MESOS-2522

Re: Typed Error Handling in Mesos

+1 This is also similar to how errors are typed in Go as well. On Wednesday, April 6, 2016, Alexander Rojas wrote: > +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

Re: Typed Error Handling in Mesos

+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 wrote: > > Contrary to standard C++ practices, Mesos uses return values as the > mechanism > for error handling rather than e

Typed Error Handling in Mesos

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