A friendly programming language from the future.

  • robinm@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    2 年前

    I’m surprised about this statement, I would have said that exceptions are the consequence of an impure operation (that may or may not fail differently every time you call it).

    • steersman2484@sh.itjust.works
      link
      fedilink
      arrow-up
      1
      ·
      2 年前

      I’m currently learning functional languages and have only limited knowledge, but from what I’ve read now you are right. Throwing exceptions is pure, but catching them is impure.

      In this case I guess the printLine function can throw an exception therefore the calling function must be declared with Exception?

      • robinm@programming.dev
        link
        fedilink
        arrow-up
        2
        ·
        2 年前

        I would even have said that both throwing and catching should be pure, just like returning an error value/handling should be pure, but the reason for the throw/returning error itself is impure. Like if you throw and ioerror it’s only after doing the impure io call, and the rest of the error reporting/handling itself can be pure.

        • steersman2484@sh.itjust.works
          link
          fedilink
          arrow-up
          1
          ·
          2 年前

          Sounds good,

          but would the preferred way be to use a wrapper type, which holds either the data or the error and avoid exceptions completely?

        • Pipoca@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          2 年前

          Pure functions should be referentially transparent; you should be able to replace them with whatever value they evaluate to without changing the semantics of your code.

          Throwing is referentially impure: what value do you get from calling x => throw new RuntimeException()?

          Instead, functional languages prefer to return a tagged union of the value or the error.