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.
