![\"Fooling](\"https:\/\/www.gamlor.info\/wordpress\/wp-content\/uploads\/2010\/02\/java-fool-checked-exceptions.png\" "\\"java-fool-checked-exceptions\\"")
<\/a>Fooling Checked Exceptions<\/p><\/div>\n
Everyone who\u2019s programming Java knows checked exceptions. You only can throw a checked exception when you\u2019ve declare it. And you have to catch an checked exception, no matter whether it actually can occur.<\/p>\n
First my opinion: I think check exception are a failure. The intention was good, but in practice they cause pain, boilerplate-code and in general cause more problems than they solve.<\/p>\n
So in my code I avoid checked exceptions. Unfortunately the existing JAVA-API\u2019s are littered with checked exceptions. So I still need to deal with them. The usual strategy looks like this:<\/p>\n
try<\/span>{\r\n someObject.doOperation();\r\n} catch<\/span>(OperationException e){\r\n throw<\/span> new<\/span> RuntimeException(\"See inner exception\"<\/span>,e);\r\n}<\/pre>\nThis works fine, but fills up the stack-trace with unnecessary garbage. (grey= garbage, black= important). And because you normally have multiple such rethrow-blocks in your code, the cause is nested somewhere in a huge stack trace:<\/p>\n
Exception in thread \"main\" java.lang.RuntimeException: See inner exception\r\n at ch.gamlor.test.ExceptionBlogPost.methodWithoutCheckedException(ExceptionBlogPost.java:27)\r\n at ch.gamlor.test.ExceptionBlogPost.openSimulation(ExceptionBlogPost.java:20)\r\n at ch.gamlor.test.ExceptionBlogPost.demostrateStackTrace(ExceptionBlogPost.java:15)\r\n at ch.gamlor.test.ExceptionBlogPost.main(ExceptionBlogPost.java:11)<\/span>\r\nCaused by: ch.gamlor.test.OperationFailedException: Could not find appropriate example\r\n at ch.gamlor.test.ExceptionBlogPost.legacyMethodWithCheckedExceptions(ExceptionBlogPost.java:32)\r\n at ch.gamlor.test.ExceptionBlogPost.methodWithoutCheckedException(ExceptionBlogPost.java:25)\r\n ... 3 more<\/pre>\nThe Hack<\/h3>\n
Now recently I\u2019ve discovered this post on StackOverflow<\/a>, about unknown \u2018features\u2019 of the Java language. There someone showed how to throw checked exception without declaring them<\/a>. Basically he combines the exception with generics and misuses the type erasure of the compiler<\/a>, so that the type of the exception is erased =). Btw. the post includes another surprise: You can declare a class in methods =).<\/p>\nHere\u2019s the code and more details how it works:<\/p>\n
public<\/span> final class<\/span> UncheckedThrow {\r\n private<\/span> UncheckedThrow(){}\r\n\r\n public<\/span> static<\/span> void<\/span> throwUnchecked(final Exception ex){\r\n \/\/ Now we use the 'generic' method. Normally the type T is inferred<\/span>\r\n \/\/ from the parameters. However you can specify the type also explicit!<\/span>\r\n \/\/ Now we du just that! We use the RuntimeException as type!<\/span>\r\n \/\/ That means the throwsUnchecked throws an unchecked exception!<\/span>\r\n \/\/ Since the types are erased, no type-information is there to prevent this!<\/span>\r\n UncheckedThrow.<RuntimeException>throwsUnchecked(ex);\r\n }\r\n\r\n \/**<\/span>\r\n * Remember, Generics are erased in Java. So this basically throws an Exception. The real<\/span>\r\n * Type of T is lost during the compilation<\/span>\r\n *\/<\/span>\r\n public<\/span> static<\/span> <T extends Exception> void<\/span> throwsUnchecked(Exception toThrow) throws T{\r\n \/\/ Since the type is erased, this cast actually does nothing!!!<\/span>\r\n \/\/ we can throw any exception<\/span>\r\n throw<\/span> (T) toThrow;\r\n }\r\n}<\/pre>\nNow you just can use this method to \u2018rethrow\u2019.:<\/p>\n
try<\/span>{\r\n legacyMethodWithCheckedExceptions();\r\n} catch<\/span> (OperationFailedException e){\r\n UncheckedThrow.throwUnchecked(e);\r\n}<\/pre>\nAnd surprisingly this works! And even better, no rethrow-garbage, and also the throw location is right!<\/p>\n
Exception in thread \"main\" ch.gamlor.test.OperationFailedException: Could not find appropriate example ;)\r\n at ch.gamlor.test.ExceptionBlogPost.legacyMethodWithCheckedExceptions(ExceptionBlogPost.java:32)\r\n at ch.gamlor.test.ExceptionBlogPost.methodWithoutCheckedException(ExceptionBlogPost.java:25)\r\n at ch.gamlor.test.ExceptionBlogPost.openSimulation(ExceptionBlogPost.java:20)\r\n at ch.gamlor.test.ExceptionBlogPost.demostrateStackTrace(ExceptionBlogPost.java:15)\r\n at ch.gamlor.test.ExceptionBlogPost.main(ExceptionBlogPost.java:11)<\/pre>\n\u00a0<\/p>\n
Fine Tuning The Hack<\/h3>\n
Now we\u2019re facing the next problem. Supposed we\u2019ve a method which returns a value and we use out little hack. Then we\u2019ve a problem. Since the compiler doesn\u2019t see the \u2018exception\u2019, it requires you to return something or throw something. Well that\u2019s easy to fix. Change the signature from void to RuntimeException, so that you can throw it. But the implementation never actually returns, but throws the suppress checked exception.<\/p>\n
public<\/span> final class<\/span> UncheckedThrow {\r\n private<\/span> UncheckedThrow(){}\r\n\r\n \/\/ Now this returns an exception, so that you can satisfy the compiler by throwing it.<\/span>\r\n \/\/ But in reality we throw the given exception!<\/span>\r\n public<\/span> static<\/span> RuntimeException throwUnchecked(final Exception ex){\r\n \/\/ Now we use the 'generic' method. Normally the type T is inferred<\/span>\r\n \/\/ from the parameters. However you can specify the type also explicit!<\/span>\r\n \/\/ Now we du just that! We use the RuntimeException as type!<\/span>\r\n \/\/ That means the throwsUnchecked throws an unchecked exception!<\/span>\r\n \/\/ Since the types are erased, no type-information is there to prevent this!<\/span>\r\n UncheckedThrow.<RuntimeException>throwsUnchecked(ex);\r\n\r\n \/\/ This is here is only to satisfy the compiler. It's actually unreachable code!<\/span>\r\n throw<\/span> new<\/span> AssertionError(\"This code should be unreachable. Something went terrible wrong here!\"<\/span>);\r\n }\r\n\r\n \/**<\/span>\r\n * Remember, Generics are erased in Java. So this basically throws an Exception. The real<\/span>\r\n * Type of T is lost during the compilation<\/span>\r\n *\/<\/span>\r\n public<\/span> static<\/span> <T extends Exception> void<\/span> throwsUnchecked(Exception toThrow) throws T{\r\n \/\/ Since the type is erased, this cast actually does nothing!!!<\/span>\r\n \/\/ we can throw any exception<\/span>\r\n throw<\/span> (T) toThrow;\r\n }\r\n}<\/pre>\nNow you can use it anywhere!<\/p>\n
private<\/span> int<\/span> methodWithoutCheckedException() {\r\n try<\/span>{\r\n return<\/span> legacyMethodWithCheckedExceptions();\r\n } catch<\/span> (OperationFailedException e){\r\n throw<\/span> UncheckedThrow.throwUnchecked(e);\r\n }\r\n}<\/pre>\nIt\u2019s not only limited to rethrows, you can throw a checked exception anywhere. However I think that\u2019s a very bad idea!<\/p>\n
private<\/span> String demoJustThrow(){\r\n throw<\/span> UncheckedThrow.throwUnchecked(new<\/span> IOException(\"See, I'm not declared\"<\/span>));\r\n}<\/pre>\nConclusion<\/h3>\n
I\u2019ve demonstrated how to throw checked exception like unchecked ones. Yes, this is certainly a real evil hack. However I also think that avoiding unnecessary garbage in stack traces is a real benefit. So I\u2019ve started to use this for rethrowing checked exceptions in my projects.<\/p>\n
I\u2019ve also to mention that this could be a weakness in the javac-compiler. I haven\u2019t checked this against the language definition =).<\/p>\n