Error handling at XML element level

[moodmosaic]

The implementation proposed in #5 does not currently have error handling at XML element level – it only replaces the usage of attributes, as discussed in #3.

Although an XML document might have the correct versioned namespace, one or more of its XML elements might be malformed.

We could use the monads demonstrated at the Railway Oriented Programming talk and make the parsing functions composable, so we may report which XML element couldn't be parsed.

[ploeh]

As far as I can tell, we're done here, or do you think there's more work to do?

[moodmosaic]

Hm, when I opened this issue I was thinking more about making the selector functions and the parsing function return a type similar to

Result<'TSuccess, 'TFailure>

By using the functions in Rop.fs we could have error handling at XML element level so that we may report and/or log which XML elements couldn't be parsed.

Right now, I am not sure if there are benefits from this. Do you think it's worth the effort?

[ploeh]

It would be a step towards addressing #13, so I do think it would be worth the effort.

[moodmosaic]

Thinking about the

Result<'TSuccess, 'TFailure>

I think, we could just replace it with the one from Rop.fs (Railway code):

type RopResult<'TSuccess, 'TMessage> =
    | Success of 'TSuccess * 'TMessage list
    | Failure of 'TMessage list

Then, it will be easier to use the rest of the functions in the Railway code. What do you think?

---

If we take this direction, and since we are using NuGet, instead of including the Railway code as a file in the project, perhaps we could add it as a NuGet package.

[moodmosaic]

As it looks like, FSharpx.Core has a more cohesive approach; it encapsulates both the Either monad and it goes a step forward, defining a choose Computation Expression.

This allows us, for example, to re-write the handle function as:

let rec handle (getMessage) (deleteMessage) (sendEmail) msg =
    match msg |> parse with
    | EmailMessage.EmailData mail ->
        mail |> sendEmail |> Choice1Of2
    | EmailMessage.EmailReference ref ->
        choose {
            let! message = ref.DataAddress |> getMessage
            do! message |> handle getMessage deleteMessage sendEmail
            do! ref.DataAddress |> deleteMessage }
    | _ -> UnknownMessageType |> Choice2Of2

And since FSharpx.Core defines an Active Pattern to represent the Result we may still get rid of the

Result<'TSuccess, 'TFailure>

[ploeh]

That looks nice :)