3 ms·
Checked exception in a Optional.get is really the worst idea that you could possibly come up with. Have a look at vavr (https://github.com/vavr-io/vavr https:/
by Blackarea 2y ago
Checked exception in a Optional.get is really the worst idea that you could possibly come up with.
Have a look at vavr (https://github.com/vavr-io/vavr https://github.com/vavr-io/vavr)
They did a fantastic job and the DX is so much better than anything java std has to offer. They have immutable equivalents for pretty much any java util data structure as well as either try option etc. To me the one lib that makes java actually feel fresh.
- gylterud 2y agoVavr 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.