fp-ts Tutorial | Chapter 2.3: Option error handling

Sdílet
Vložit
  • čas přidán 27. 07. 2024
  • In Chapter 2.3 of this fp-ts tutorial (functional programming in TypeScript), we will see a concrete example of how to do error handling with Option.
    More specifically, we will introduce the Option alt util, which allows us to perform an alternative computation in case the previous computations failed.
    00:00 Introduction
    01:01 getMovieHighlight implementation
    02:28 Option alt definition
    02:39 Implementation continued
    03:10 Step by step walk-through
    06:20 Option altW

Komentáře • 12

  • @ShawnShaddock
    @ShawnShaddock Před rokem +6

    So you can pipe a series of alts together to perform coalescing, eg. you have multiple possibly None values, and you want the first one that isn't None

    • @MrFunctor
      @MrFunctor  Před rokem +4

      Yep, that's right! 👍 You can have multiple alts in sequence and you will keep executing them until one of them succeeds (i.e., returns a Some) or they all fail (i.e., all return None).

  • @dawid_dahl
    @dawid_dahl Před rokem

    Wonderful, thank you! Shed some light on two concepts I’ve been wanting to learn more about, namely .alt as well as W (Widen).
    Is that how I should think when I encounter the W in the various methods? That the return type can be different than the original? Or was that only for this specific context?

    • @MrFunctor
      @MrFunctor  Před rokem +2

      Hello Dawid!
      Yes, that's how you should think when you encounter methods that end in W: it just stands for Widen/Widening with the meaning that it is widening the return type. 👍
      Most of the time, you don't want to unintentionally widen return types, so the default behavior tends to enforce that the return type remains the same. In a few cases, where you do need to widen the type, you have to explicitly call the W variant of a particular method.

    • @dawid_dahl
      @dawid_dahl Před rokem

      @@MrFunctor Perfect, thank you!

  • @rafaelhernand3z
    @rafaelhernand3z Před rokem

    Is this approach cleaner that using fold?

    • @MrFunctor
      @MrFunctor  Před rokem +3

      Remember that fold is just an alias for match, which is used for pattern matching, as explained in Chapter 2. So, when you use match (or fold), you are explicitly handling both the None case and the Some case. So, you could in theory emulate the behavior of alt by writing something like O.match(() => alternativeComputation(...args), O.some), however, not only that is more verbose, but it also doesn't tell your intention to the reader as clearly as O.alt does.

  • @CuriousSpy
    @CuriousSpy Před rokem +4

    [Option] is not really an error. It's an optional value. [Either] is more suitable for error handling. Option just tells you if value exists or not. In real world it would be Either

    • @MrFunctor
      @MrFunctor  Před rokem +1

      That is not accurate. Option can be used to "represent the effect of a possibly failing computation" as stated in the fp-ts documentation. In fact, in the case in which you don't care about an error message or error type and you only want to know if the computation succeeded or not, you can totally use Option. Even in other languages, like Haskell, the Maybe monad (the equivalent of Option in fp-ts) can represent the result of a computation that can fail. Also in Rust, in the std::option module docs, it states that one of the uses of Option is as "Return value for otherwise reporting simple errors, where None is returned on error."

    • @CuriousSpy
      @CuriousSpy Před rokem

      @@MrFunctor sure you can. But its confusing when there is no context of your "error". That's why I'm saying its not really an error. Computation can fail with many reasons. For example it's not ok to return Option when you parse uuid, or divide by zero but some people do it.
      To summarize: technically it is "simple error" or fail. In real world you never use Option as an error

    • @MrFunctor
      @MrFunctor  Před rokem

      Yeah, I agree that when you have a function that may fail for different reasons, you should return an Either to be able to specify the kind of error that caused the function to fail. However, there are also cases in which you have simple functions that can fail for only one obvious reason and in those cases it makes sense to return an Option. In the video, we have getMovieAwardHighlight, which is a function that tries to get the movie.award and return an award highlight. However, if the movie has no award, this function "fails" and returns a None. So, in this case, it is clear that if you got a None, it must be because the movie has no award. The same applies to getMovieTop10Highlight: the only reason why that function may fail is because the movie is not in the top 10, so it cannot return a TOP 10 highlight, and that's why it's fine for it to return an Option.

    • @CuriousSpy
      @CuriousSpy Před rokem +1

      @@MrFunctor again - no problem with using an option. My problem is i cant call it an "error"