CLR exceptions

[pimbrouwers]

• Removes Result from execution pipeline.
• Introduces SqlType help functions.

[sbacquet]

This is a major breaking change.
What is the rationale behind ?

[pimbrouwers]

Indeed, which is why it was a major package number bump. Was an experienced-based decision based on writing hundreds of programs, noticing that there was hardly a salient use case for handling errors monadically. If the DB execution fails, what are you reasonably going to do other than log/report the error?

…

On Thu., Jul. 27, 2023, 11:36 a.m. Sebastien Bacquet, < ***@***.***> wrote: This is a major breaking change. What is the rational behind ? — Reply to this email directly, view it on GitHub <#54 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDB57P4NVNJQZ6VEU6EUFDXSKDI5ANCNFSM6AAAAAA2CZN4WY> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[sbacquet]

Indeed, which is why it was a major package number bump.

Ok, but I guess branch 9.x will not be maintained ;)

there was hardly a salient use case for handling errors monadically

Are you talking about DB execution specifically, or in general ?

If the DB execution fails, what are you reasonably going to do other than log/report the error?

DB execution is just a step in monadic pipelines.
Throwing exceptions is not idiomatic and breaks the pipeline.
To me, returning Result<'T, System.Exception> is the best way to manage errors in F#.

Anyway for Donald it's not a big deal : I'll surround the calls to Db.exec and Db.Async.exec with try/with and return Error exception.

[pimbrouwers]

I never said that. I am more than happy to patch version 9.x if issues come up. Is there a specific issue you've been facing? My last response was specifically about database execution, there is clearly a very well demonstrated use for monadic error handling. I wouldn't say this change prevents you from using this in pipelines at all. The library produces a limited number of exceptions, so creating an adapter function should be quite simple. I considered including it, but after some discussion with a few other devs, opted against it. Happy to consider that as well, if that would suit you? I apologize for the inconvenience.

…

On Fri., Jul. 28, 2023, 5:31 a.m. Sebastien Bacquet, < ***@***.***> wrote: Indeed, which is why it was a major package number bump. Ok, but I guess branch 9.x will not be maintained ;) there was hardly a salient use case for handling errors monadically Are you talking about DB execution specifically, or in general ? If the DB execution fails, what are you reasonably going to do other than log/report the error? DB execution is just a step in monadic pipelines. Throwing exceptions is not idiomatic and breaks the pipeline. To me, returning Result<'T, System.Exception> is the best way to manage errors in .NET. Anyway for Donald it's not a big deal : I'll surround the calls to Db.exec and Db.Async.exec with try/with and return Error exception. — Reply to this email directly, view it on GitHub <#54 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDB57NIK5SYTPPVP3JFKRDXSOBIFANCNFSM6AAAAAA2CZN4WY> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[sbacquet]

Donald is working like a charm, thanks for publishing this nice library :)
I'll adapt my code to version 10, no worries.

[pimbrouwers]

My pleasure. Very glad you like it! I do as well!

…

On Fri., Jul. 28, 2023, 9:12 a.m. Sebastien Bacquet, < ***@***.***> wrote: Donald is working like a charm, thanks for publishing this nice library :) I'll adapt my code to version 10, no worries. — Reply to this email directly, view it on GitHub <#54 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDB57PZLX45ZHU575T77YLXSO3D3ANCNFSM6AAAAAA2CZN4WY> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[sbacquet]

Hello - sorry to bother you
I'm migrating my code to version 10 with CLR exceptions.
The exceptions that I'm catching are of type : AggregateException -> Inner = Donald.DbExecutionException -> Inner = OracleException
That's a lot of layers. Do you know why an AggregateException is thrown and how to avoid it ?
Thanks !

[sbacquet]

OK the issue is within Async.AwaitTask, which does not unwrap properly the exception thrown in another thread.
It's actively discussed here and should be fixed some day in F#.

To confirm the issue, the following test fails :

    [<Fact>]
    member _.``SELECT records async should fail`` () =
        let sql = "
            SELECT author_id, full_name
            FROM   fake_author"

        let query () =
            try
                conn
                |> Db.newCommand sql
                |> Db.Async.query Author.FromReader
                |> Async.AwaitTask
                |> Async.RunSynchronously
                |> ignore
            with ex ->
                ex |> ignore

        query |> should throw typeof<DbExecutionException>

which is just the async version of test SELECT records should fail.

[sbacquet]

I've ended up with the following adapter :

let rec donaldExToError (ex:Exception) =
    match ex with
    | :? Donald.DbConnectionException as ex ->
        Error ex.InnerException
    | :? Donald.DbExecutionException as ex ->
        Error ex.InnerException
    | :? Donald.DbTransactionException as ex ->
        Error ex.InnerException
    | :? Donald.DbReaderException as ex ->
        Error ex.InnerException
    | :? AggregateException as ex ->
        donaldExToError ex.InnerException
    | ex ->
        Error ex