{"id":78,"date":"2020-12-23T09:10:40","date_gmt":"2020-12-23T07:10:40","guid":{"rendered":"http:\/\/victorrentea.ro\/blog\/?p=78"},"modified":"2020-12-25T07:29:19","modified_gmt":"2020-12-25T05:29:19","slug":"hide-checked-exceptions-with-sneakythrows","status":"publish","type":"post","link":"https:\/\/victorrentea.ro\/blog\/hide-checked-exceptions-with-sneakythrows\/","title":{"rendered":"Hide Checked Exceptions with SneakyThrows"},"content":{"rendered":"
<\/div>

Java is the only programming language in the world that has checked exceptions, which forces the caller to know about the individual exception types thrown by the called function.<\/p>\n

What do you do when you face a checked exception? As we will see in a later blog post<\/a>, propagating checked exceptions through your code is both leaking implementation details, annoying, and even dangerous. That’s why in the vast majority of cases you should catch-rethrow it as a runtime exception, and let it "silently" terminate your current use-case.<\/p>\n

This article introduces a "magic" way to generate that code that we wrote dozens\/hundreds of times in our career. Here’s a reminder:<\/p>\n

public static Date parseDate(String dateStr) {\n    try {\n        SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd");\n        return format.parse(dateStr);\n    } catch (ParseException e) {\n        throw new RuntimeException(e); \/\/ this :(\n    }\n}<\/code><\/pre>\n
If you are sick to do this catch-rethrow manually, here’s the @SneakyThrows<\/code> annotation coming from the magic realm of the Project Lombok<\/a>.<\/p>\n
Let’s just annotate our method with it and simply remove the catch<\/code> clause:<\/p>\n
@SneakyThrows\npublic static Date parseDate(String dateStr) {\n    SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd");\n    return format.parse(dateStr);\n}<\/code><\/pre>\n
Doing so will instruct the Lombok annotation processor to hack the bytecode generated by the javac compiler, allowing the code above to compile, altough there’s no catch<\/code>, nor throws<\/code> clause for the ParseException<\/code>.<\/p>\n
\n
Warning<\/strong>: the Java IDE you use must be hacked (see here<\/a> how).<\/p>\n<\/blockquote>\n
Knowing that Lombok is able to change your code as it\u2019s compiled<\/strong>, one might expect that the current body of our function will be surrounded by <\/p>\n
try { ... } catch (Exception e) { throw new RuntimeException(e); }<\/code><\/pre>\n
That\u2019s a fair expectation. Indeed, the checked exception is not swallowed but thrown back out of the function.<\/p>\n
However, since Java8, Lombok does it in a bit unexpected way. To see what it really does, let’s decompile the .class<\/code> file:<\/p>\n
public static Date parseDate(String dateStr) {\n    try {\n        SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd");\n        return format.parse(dateStr);\n    } catch (Throwable var6) {\n        throw var6;\n    }\n}<\/code><\/pre>\n
Indeed, Lombok did add a try-catch block around the body of my function, but it caught a Throwable<\/code> and rethrew it without wrapping it at all!<\/p>\n
Something is wrong!<\/p>\n
That Throwable<\/code> must have been declared in a throws<\/code> clause on the function!<\/p>\n
If you copy-paste the code in a .java file, you\u2019ll quickly see that this code doesn\u2019t compile!! But how was it compiled in the first place?!<\/p>\n
To understand how’s that even possible, you have to learn that the distinction between checked and runtime exceptions is only enforced by the Java compiler (javac). The Java Runtime (JVM) does NOT care what kind of exception you throw – it propagates any exception down the call stack the same way. So the Lombok processor tricked javac into producing bytecode that represents code that wouldn\u2019t actually be compilable.<\/p>\n
Panic!\n\"file\"<\/p>\n
But a minute after you calm down, you get this strange thought: if the checked exception is invisibly thrown, how would you then be able to catch it later? Let’s try:<\/p>\n
try { \n    parseDate("2020-01-01"); \n} catch (ParseException e) {...}<\/code><\/pre>\n
But this doesn’t compile because nothing in the try<\/code> block throws a ParseException<\/code>. And javac will reject that. See for yourself: commit<\/a><\/p>\n
So what does this mean? It means that the exceptions hidden using @SneakyThrows<\/code> aren\u2019t supposed to be caught again individually. Instead, a general catch (Exception)<\/code> not ~catch (RuntimeException)<\/code>~ should be in place somewhere down the call stack to catch the invisible checked exception<\/em>. For example if you are handling Spring REST endpoint exceptions using @RestControllerAdvice<\/code>, make sure you declare to handle Exception.class<\/code>. More details in an upcoming article<\/a>.<\/p>\n
Some of you might be disgusted at this point. Others might be super-excited. I\u2019m not here to judge but only to report the techniques that have become wide-spread in the hundreds of projects I trained or consulted for. I agree that this can be misused if careless, so judge whether to use this feature responsibly.<\/p>\n
Okay, okay… But why?!<\/p>\n
Because Java is an old language. 25 years is a long time to carry some baggage. So today Lombok is effectively hacking the language to make us write less and more focused code.<\/p>\n
Conclusion<\/h2>\n