Seems the easiest way to address that is with a DSL and a code generator.
> On Jun 18, 2023, at 9:47 AM, Jan Pfeifer <pfei...@gmail.com> wrote:
>
>
> hi Shulhan, I see your points, thanks for the reply. Let me comment on them
> below:
>
>> On Sat, Jun 17, 2023 at 9:21 AM Shulhan <m.shul...@gmail.com> wrote:
>> Hi Jan, thanks for response.
>>
>> On Mon, 5 Jun 2023 01:06:37 -0700 (PDT)
>> Jan <pfei...@gmail.com> wrote:
>>
>> > Repeating Justin's consideration: one of my (and from colleagues I
>> > discuss the topic with) major issues with current error handling is
>> > the repetition of identical code. Your proposal still requires `when
>> > err handle ...` at every statement.
>>
>> Yes, correct.
>> The idea is not to minimise repetition on error handling statement, the
>> "if err != nil", but to minimise repetitive error handling body by
>> grouping it into single handle based on the context of error.
>
> Oh, I see. I have to say I wish one didn't need to do the `if err != nil` all
> the time either, when the handling is the same :) But if that is your
> proposal it makes sense.
>
>> > It also doesn't allow for nested
>> > call of functions that return errors -- e.g: `f(g(h(x)))`, where `h`,
>> > `g`, and `f` can return errors (all presumably handled the same way).
>> >
>>
>> I am not sure I understand this, but should not each function handle it
>> on its own?
>> Or should not `f` being called if `g` return an error?
>> If its later, yes, it does not allow for nested handling of error.
>
> Sorry I was not clear. What I mean is, with current error handling would be
> written like:
>
> hValue, err := h(x)
> if err != nil {...}
> gValue, err := g(hValue)
> if err != nil {...}
> fValue, err := f(gValue)
> if err != nil {...}
>
> Where all of the `if err` are identical.
>
> Let me provide a more concrete example: I'm working on an ML framework
> (github.com/gomlx/gomlx), and I'm writing computational graphs (that get
> just-in-time compiled for speed/GPU support) like:
>
> func EuclideanDistance(x, y *Node) *Node {
> return Sqrt(ReduceAllSum(Square(Sub(x, y))))
> }
>
> Where each of these functions could return an error (if shapes are
> incompatible). If an error is raised (they hold a stack trace), I want them
> simply propagated upwards. Error handling in the middle of these math
> expressions (some are larger) get in the way of the math being expressed.
>
> cheers
> Jan
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAE%3D7LsUQfPLP1w0s9EN3XZSsoproEStkQHRb-s8pcdTgmpbzTw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/6115E519-3E68-4DD2-877D-66EB54ECA26F%40ix.netcom.com.
