• lysdexic@programming.dev
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    8
    ·
    2 months ago

    The problem is that you need some support from the language to make it easy to deal with.

    Nonsense.

    if (result.isSuccess()) {
        do_something(result.value);
    }
    else {
       handle_error(result error);
    }
    
    • lad@programming.dev
      link
      fedilink
      English
      arrow-up
      7
      arrow-down
      1
      ·
      2 months ago

      I feel like this will have zero protection against

      if (result.isSuccess()) {
          handle_error(result.error);
      } else {
          do_something(result.value);
      }
      

      Besides, this is exactly what the comment said about having to constantly check for return values at call site. I think this may be mitigated by some clever macro-magic, but that will become a mess fast.

      • lysdexic@programming.dev
        link
        fedilink
        English
        arrow-up
        1
        arrow-down
        3
        ·
        2 months ago

        I feel like this will have zero protection against

        Zero protections against what? Against the programmer telling the program to do something it shouldn’t? Not programming language does that. If you resort to this sort of convoluted reasoning, the same hypothetical programmer can also swallow all exceptions.

        The main problem you’re creating for yourself is that you’ve been given an open-ended problem but instead prefer to not look for solutions.

      • yoevli@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        arrow-down
        9
        ·
        2 months ago

        I mean, technically there’s nothing preventing that, but in practice it’s a fairly uncommon mistake to make and it’s immediately obvious that there’s an issue the first time that path is taken. If something like that makes it to production, it clearly points to an issue with test coverage rather than code paradigm.