3 ms·
Vavr is nice! But I understand the want to make the get exception checked. It makes it so that you can use try/catch as a Java-man’s do-notation, and not fear h
by gylterud 2y ago
Vavr is nice! But I understand the want to make the get exception checked. It makes it so that you can use try/catch as a Java-man’s do-notation, and not fear having forgotten to deal with the None case.
You can then make lots of utility functions which all get without handling it (only declare that they throw) and then you compose these into larger functions which make sure to catch at the end.
Having to declare it makes it really clear what the function actually does.
- Blackarea 2y agoCan you provide an example. I just don't see it tbh. Especially since closures in java really don't work with checked exceptions at all. That's why vavr avoids it at all costs. Eg: ```java assertEquals( Vector.of(1, 3), Vector.of(Some(1), None(), Some(3)) .filter(Option::isDefined) .map(Option::get) ); ``` If `Option.get` was throwing a checked you'd always have to wrap it in try-catch. I understand that this is a break with the type system (meaning it is not strong typed Maybe/Option in that sense). But otherwise you'd be worse of than with stupid null checks IMO.