Reputation: 143
I've made a simple Computation Expression workflow for dealing with Results.
[<RequireQualifiedAccess>]
module Result =
type Builder() =
member __.Bind(x, f) = x |> Result.bind f
member __.Return(x) = x
member __.ReturnFrom(x) = Ok x
let workflow = Builder()
I also use different types to represent different kids of errors:
type ValidationError<'a> = { Obj:'a; Message:string }
type InvalidOperationError = { Operation:string; Message:string }
The problem arises when two results have different error types.
LetterString.create : string -> Result<LetterString, ValidationError<string>>
Username.create : string -> Result<Username, ValidationError<string>>
PositiveDecimal.create : decimal -> Result<PositiveDecimal, ValidationError<decimal>>
let user =
Result.workflow {
let! name = LetterString.create "Tom"
let! username = Username.create "Tom01098"
// Error occurs here.
let! balance = PositiveDecimal.create 100m
return! {
// User record creation elided.
}
}
FS0001 Type mismatch. Expecting a
'Result<PositiveDecimal,ValidationError<string>>'
but given a
'Result<PositiveDecimal,ValidationError<decimal>>'
I have already tried using a DU type of all errors:
type Error<'a> =
| ValidationError of Obj:'a * Message:string
| InvalidOperationError of Operation:string * Message:string
This has a similar problem when the generic parameter 'a
is different between errors. It also loses the exact type of error in the type signature of the function.
The expected result is that the entire workflow has a unified error type, preferably as specific as possible in terms of type.
Upvotes: 3
Views: 286
Reputation: 143
Can be solved by removing the generic parameter and using a single Error
DU. Unfortunately this loses the signature I wanted, but it will have to do.
Upvotes: 2