Could 'Error' generic parameter be removed? about result

[JaviSoto]

That is a great question, sir :)

This is how I deal with this particular issue, in my networking APIs. I create a error type that can encapsulate each of those. That way, it's also easier for the clients of this API to know which kind of error was encountered.

Example:

enum MyAPIErrorType: ErrorType {
    case JSONParsingError(NSError)
    case NetworkingError(NSError)
    case SomeOtherSpecificError(AssociatedErrorType)

So your APIs will return Result<XYZ, MyAPIErrorType>, and in the implementation you have to make sure you catch each different type of error and wrap it with the appropriate MyAPIErrorType case.

How does this sound? :)

[robrix]

Some historical context: The decision to parameterize Result by an Error was the result of a long discussion on LlamaKit (of which this framework is the spiritual successor).

@JaviSoto’s suggestion is the recommended path 👍

[damienrambout]

@JaviSoto @robrix You are absolutely right that errors should be wrapped by each layer.
It's sometimes easier to just forward the error without defining a new one... :-) Or defining global errors such as NoInternetConnection or RequestTimedOut.

Ok thanks, I'll wrap more then :-)