Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - mira9998

Stran: [1]
1
Vývoj / Re:FP a error handling
« kdy: 07. 01. 2026, 22:38:54 »
Ty vnořené větve kódu by vypadaly nějak takto:

Kód: [Vybrat]
match relativePath preparedSource entry with
 | Error err -> Error err
 | Ok relative
     ->
     match Path.Combine(target, relative) |> Option.ofNullEmpty with
     | None
         -> Error "Failed getting combined path"
     | Some dest
         ->
         match moveEntry entry dest with
         | Ok result -> Ok result
         | Error err -> Error err

2
Vývoj / Re:FP a error handling
« kdy: 07. 01. 2026, 22:12:30 »
Když už jsem se zmínil o prostředcích, které F# má pro zacházení s Result type, tak je to třeba toto computation expression (result je jméno builderu):

Kód: [Vybrat]
result
     {
         let! relative = relativePath preparedSource entry
         let! dest =
             Path.Combine(target, relative)
             |> Option.ofNullEmpty
             |> Option.toResult "Failed getting combined path"
     
         return! moveEntry entry dest
     }

Lze ještě použít monadic composition nebo ROP-style function composition (to jsou všechny ty Result.bind/map/either a kyble dalších funkcí). Bez nich nebo bez výše uvedeného CE bychom měli tři vnořené větve pattern matchingu.

3
Vývoj / Re:FP a error handling
« kdy: 07. 01. 2026, 18:24:37 »
No, F# bylo mj. navržené tak, aby byla možná interoperabilita s .NET knihovnami, ze kterých se do F# plíží logicky jak nulls, tak i exceptions z System.Exception. Knihoven čistě funkcionálních, které mají na výstupu Option nebo Result, je málo (např. Thoth.Json).

Mimochodem, F# má ještě zjednodušenou funkci failwith, která vyhodí běžnou System.Exception. Co vím, vyhazování exceptions se používá jen výjimečně, kdy je neúčelné vytahovat Result type někde z útrob kódu.

V F# musíš manuálně převádět exceptions/nulls do Result/Option. No, jako, nemusíš, když nechceš, ale pak neprogramuješ funkcionálně. A proč tedy Result/Option, je tvá hlavní otázka, že? Můžeš se zeptat ChataGPT, ale jeho odpověď ti asi nedá takovou představu, jako když si to zkusíš osobně a uvidíš sám, jak se v code flow pracuje s Option/Result (můj subjektivní názor je, že je to super sqělé) a FP jazyky na to mají prostředky, takže nemáš všude pyramid of doom (plno vnořených větvení), jak se zmiňoval nějaký FP hater neznající funkcionální prvky. Domnívám se, že je to asi jediná cesta k plnému pochopení vhodnosti Option/Result (v Haskellu a jiných jazycích se to nazývá jinak, ale jedná se stejný princip). Koneckonců pokud bys chtěl spolupracovat s některou FP firmou, budou chtít Option/Result, ne exceptions, viděl jsem to přímo v textech inzerátů (připrav se na něco takového https://github.com/MiroslavHustak/FSharp-Coding-Guidelines ).

Všimni si, že máš většinou dva stavy - vyhovující a nevyhovující (žádoucí výsledek/null, žádoucí výsledek/exception), no, a k tomu pasuje discriminated union (sum type, enum atd. v jiných jazycích), což jsou Option/Result types. Takže taháš obou-stavové řešení bezpečně až třeba do nějaké transformation layer mezi FE a BE https://github.com/MiroslavHustak/OdisTimetableDownloaderMAUI/blob/master/ApplicationDesign/KODIS_Record4.fs. Ale jak jsem psal, nejlépe je si to zkusit sám.

Async.Catch neháže exceptions, ale převádí je na typ Choice<'a,'exn>, což je předchůdce dnešního Result (takže dnes se tam přidá Result.ofChoice a je to tam, kde to chceme mít).

Sorry za používání anglických výrazů, ale jsem jen samouk všechno studující z anglických podkladů.

Stran: [1]