Alas, sometimes even a Slytherin must code in Java. Java's endemic flaw is that it never has enough features; in this it is infinitely preferable to, say, C++, which always has too many! The consequence of this flaw is that we must write lots of redundancies. A redundancy is a statement that offers no possibility for expression, but that we must write anyway. This is drudgery, mere toil, not befitting our high nature! Java has long supported some functional idioms and even anonymous classes, but using them was an exercise in managing redundant boilerplate. Java 7 helped clear some Generics-related boilerplate, but Java 8's compact lambda expressions and Streams API finally made functional expressions look good on the page.
There's just one problem: what if your lambda expression calls some function that throws a checked exception? Streams methods won't accept such a lambda! This sort of problem predates Java's lambdas and Streams, but now that functional idioms are good-looking enough to use it's a problem worth re-examining. So let's consider the possibilities.
You could handle the exception. Yeah, right. In your nice, pithy lambda? What are you, a Hufflepuff? You didn't throw that exception, it's not your responsibility. Let someone else handle it.
You could catch it, wrap it in RuntimeException, and throw that. You'd do that with a higher-order function, obviously. The downside to this is that by wrapping the checked exception you obscure its true nature to callers. That's a red flag right there (we obviously prefer green ones). Another core Slytherin value this violates is reciprocity. You had to deal with the annoyance of a checked exception and it's your right to propagate this annoyance up the call stack. But to force the caller to check arbitrary levels of getCause() and try to guess the intentions of the various wrapping layers? I'm not going to lecture you about fairness or the social contract, but think of the possible consequences: your caller could denounce your method for being imprecise. You don't want that reputation. It's just this fear that makes us civilized; do heed it.
You could wrap the exception to get it through the Streams expression, then catch it outside and unwrap it for the caller. For this you need a more specific type than RuntimeException, one that is only used for this purpose — if you wouldn't make your caller guess at the meaning of a caught RuntimeException you certainly shouldn't have to do it. This is the Golden Rule of Entitlement shared by all Slytherins, in case you were already developing a habit of skipping class by Kindergarten. So you declare such a type along with your function-wrapper and take care to use it consistently. But now your aesthetic is starting to slip. I once had such code reviewed by a Ravenclaw that commented, “That's an awful lot of control-flow just to avoid a for loop.” I could only sulk, “And an awful lot of type-names just to avoid a builder,” and take my laptop and cognac into the stairwell to rewrite the whole module, newly enlightened to the futility of striving for beauty, for unity of expression and purpose. Never have your code reviewed by a Ravenclaw.
It turns out that the best way, for a Slytherin, was invented in 2009. Do the sneakyThrow. Like it just by the sound of the name? I thought you might. You still have to wrap your lambda expression, but you don't need an extra try-catch block around the Streams expression, and the exception that comes out is exactly the type that was thrown. All you did was abuse Generics so you could make an unchecked cast and deliberately make that cast incorrectly to an unchecked type1 to fool the complier's static exception-type checks — the ends justify the means. Now you can put a (correct) throws declaration on your method, tie it up in a nice little bow, and laugh as the compiler warns you about it: how naïve it is, how little it knows of the dark arts.
You could also leave the throws declaration off and lift the burden of checked-exception handling from your caller. This could have real consequences: there are exception-handling schemes out there that rely on the methods they invoke to honor their declarations. Some Slytherins would say that the weakness of those that trust in the honor of others is their own fault, that we should not be blamed for doing what we must. I mean, it's just code, so do whatever, but don't be a douchebag about stuff that really matters, OK?
1 Two different meanings of “unchecked” in one sentence... oh, dear... ↵
No comments:
Post a Comment