The potential for JSON parsing to fail is encoded in its
type, not in the potential for a variable to null, or
false, or for an exception to have been thrown. You’re
leaning on the compiler to tell you if you’ve handled the
failure cases properly, as the code won’t compile
otherwise. Now instead of testing for runtime exceptions
you only test to make sure that your business logic is
correct.
Last time I did Java (it like 7 years ago) the compiler did enforce exceptions types as part of the signature. Has this changed in between? Otherwise this does not seem like a valid argument to me.The OP does discuss checked expcetions a little bit: Checked exceptions guarantee that someone will deal with
the issue, but they are extremely annoying, and might
result in disparate and different exception handlers all
over the place.
They don't explain why exceptions are annoying (because the compiler checks them, just like optional?) and technically there should be exactly the same number of try-catch handlers as match calls in equivalent Optional<> code... It seems to me that his arguments are mostly based on aesthetics. Something the author half-acknowledges by starting their discussion with "Well, first off I think it’s beautiful."There are some actual problems with exceptions though: 1. It may be hard to tell from looking at the code which particular calls inside a function produce which particular kinds of exceptions. 2. This is particularly problematic with stateful code, as to ensure exception-save stateful transactions. 3. They tend to be more expensive for the exceptional codepath -- on the other hand, they are faster than Optional for the non-exceptional path! In my experience points 2 and 3 are the most important. Since in Java many things may throw, one has two think about exception safety anyways most of the time. This is also a good argument maybe, to just avoid statefulnes instead. Point 3 is very important. Maybe exceptions should be relegated to truly exceptional situations, and not be used as a replacement for an if. Optional<>/Either<> is excellent in this sitiation. Still in some languages do use exceptions for this and familiarity might be something to consider there (I'm thinking of idiomatic Python signals iteration end or key presence in maps, but Python also has very different performance characteristics as Java and does not have static types for the most part anyways...). As much as I actually love FP, and I am also trying to bring more FP to other languages (C++), I don't believe in fighting the language for the sake of it. Having a nuanced conversation about the "why" and a the "when" is important. Specially when bringing these techniques to communities that are not used to them and, at the end of the day, already have methods that "Just Work TM". Otherwise, you end up having reactions like this: https://news.ycombinator.com/item?id=13505620 |