• 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
      2
      ·
      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.