Purpose of ErrorType?

[indragiek]

I'm a bit confused as to the purpose of using ErrorType as the type for the Error case of Result. Doesn't this mean that if I wanted to pull an NSError out of the enum, I would have to cast it to an NSError to do anything with it? It seems like Result should only support errors of type NSError, and an implementation of Either should be added to this library for the case where both the left/right values are parameterized (like when you want to use something other than NSError).

[rnapier]

This was based on input from @BradLarson:

https://groups.google.com/d/msg/llamakit/cQdv2i2A4Zw/FYP10NuRYOwJ

Implementing errors as an enum rather than an NSError is quite powerful since it allows you to validate that you have considered all possible error conditions (something that isn't possible with NSError).

The problem with Either<MyError, T> is that you can't flatMap it over things that may return different kinds of errors.

That said, Either<ErrorType, T> could provide that functionality, leaving Result for purely NSError-based issues. I'm not closed on this issue; I'm interested in how it impacts both uses cases. Can you give an example on the llamakit list (linked above) of how it's impacting code so that we can compare notes with Brad's case?

[jspahrsummers]

I think the biggest problem that @indragiek has pointed out—which I didn't think of originally—is that to do anything NSError-related, you have to cast the innards of Result. That seems pretty horrible, since NSErrors can contain way more information than most custom-built alternatives (even if it's less statically verifiable).

[BradLarson]

@jspahrsummers - So what I've been doing is to use a Result type that's closer to an Either:

public enum Result<T, U:ErrorType> {
    case Success(Box<T>)
    case Failure(Box<U>)
}

This requires an explicit identification of the error type, which I actually find to be helpful and descriptive in the method or function it's used with, and it preserves type information in the return. I am using the ErrorType protocol to restrict the error return types that can be used, but I'm still using a generic for the error type itself.

This allows us to use our custom error enums (which I am liking for their clarity and safety), while still permitting NSErrors where appropriate.

Perhaps a generic for the error type, with a restriction of ErrorType, might be a better way to go here.

[BradLarson]

I could use Either as a type, but the Left / Right nomenclature is difficult for people to keep straight who haven't immersed themselves in Haskell or the like. It's also not as descriptive as Success / Failure, and I like to have the error type as the second generic element.

I like having a function signature that looks something like this:

func errorGeneratingFunction(arbitraryInput:Int) -> Result<Int, CommunicationsError> {
    return .Failure(Box(.ReadWriteTimeout))
}

I think that makes it pretty easy to see what's being returned (aside from the box that we'll hopefully be able to get rid of soon).

[indragiek]

@BradLarson +1 for this approach, this is what I ended up doing as well. Completely agree about Left/Right, it just doesn't make much sense in this context.

[jspahrsummers]

Is there any reason to preserve the ErrorType constraint, as long as the enum's members remain Success and Failure? Then you get the understandability boost, but without being prescriptive about what users can do with it.

[BradLarson]

@jspahrsummers I've gone back and forth with that. Right now, I'm using it as a constraint to prevent myself from providing any arbitrary type as a Failure result, just types that I've defined as errors. Any type can be made compliant to ErrorType trivially, marking them as acceptable for this.

I could see leaving this open, though.

[jspahrsummers]

Any type can be made compliant to ErrorType trivially, marking them as acceptable for this.

My question would be: is it ever going to be useful to refer to something as ErrorType alone? My gut says no, which inhibits its usefulness as an abstraction.

[rnapier]

Sorry I've been so silent on this; I've been thinking about other things and haven't gotten back to it. My gut feeling is that the casting problem that @indragiek mentions is really quite significant and that Result should be simpler to consume. This makes me lean back towards the original design, where Result always returned an NSError. It's always possible to wrap other arbitrary types inside of an NSError, with helpers if needed.

Votes? Final thoughts? I haven't tried this in enough live code to have a really strong opinion, and unfortunately this feels like something very hard to change once people actually use it.

[jspahrsummers]

I would like to see Result either:

1. Always use NSError
2. Always be parameterized by the value and error types (basically Either, no ErrorType protocol at all)

Between the two, the latter might be more flexible—and it's always possible to create a custom type that wraps NSError for arbitrary framework errors—but I don't have a strong preference one way or the other.

I'm definitely not a fan of the current definition, where ErrorType is hardcoded and not generic.

[rnapier]

The difference between Result<Err, X> and Result that takes an ErrorType
is how things chain if they return different kinds of errors. For example,
assume that doX wants to return a value or an NSError. doY would like to
return a value or a MyErrorEnum. If Result is parameterized on the
errortype, then you cannot >>= these. With ErrorType, you can, but the
caller must then figure out the resulting concrete error type. (And of
course with NSError-only, doY can't return MyErrorEnum directly anyway; it
would have to box it in an NSError.)

So the final type-check on the error is either a feature or a bug depending
on your desires.

The ErrorType protocol is currently empty, to say that anything you want
can be an ErrorType. It would probably be nicer to require a toString()
method on it (that would require an NSError extension, which can't
currently be exported from a module, but I understand they intend to fix
that in Swift).

I think the concept of chaining functions that come from different error
systems makes a lot of sense, which is why I'm hesitant about
parameterizing on the error type. But that's what leads me to a
lowest-common-denominator that all error-regimes should be able to agree
to, which is NSError (remembering that an NSError subclass or helper
functions on an NSError+userdict could give access to any enum values you
wanted).

This keeps leading me back to NSError…

[jspahrsummers]

@rnapier Yeah, that all makes sense. I don't think the restriction on >>= with a parameterized error type is too bad (assuming that it just means you have to use the same type), but I also understand that complicates things.

I could still go either way. 😝

[brow]

I do see the fact that you can't bind an Either<E0, A> with a A -> Either<E1, B> as a feature. If I want to write an infix operator to chain those, then I can do that, but should it really be called >>=?

[BradLarson]

If you're switching between two different error types at some portion in your chain, it doesn't seem to me that it would be appropriate to just bind and carry on at that point. In our code, that's a natural point to attempt error recovery, or to convert that lower-level error into a higher-level one that is being presented to the user or used for processing higher-up.

To me, NSError has so many problems in its design: requiring integer error code lookup tables instead of just using Swift's descriptive enum types, having a grab-bag of weakly-typed associated values in the internal dictionary, etc. We've dropped it completely in our code here in favor of Swift enums, with associated values providing error-specific supplemental data (the file that failed to open, the number of bytes you expected to read from a serial port vs. those you actually read, etc.). I'm finding these strongly-typed errors to be far better to handle and understand in our code than NSError ever was. It also eliminates a set of bugs that had bit us before (bad error code lookups, mistaken casts from the NSError's associated data dictionary).

The Result / Either type we're going to continue to use in our code will be one where the error type is parameterized. Replacing NSError with Swift enums has been a big win for us.