From b96bd7e9265c1e4b9849f151667404767c241694 Mon Sep 17 00:00:00 2001 From: Reinier Zwitserloot Date: Sat, 18 Jul 2009 03:01:44 +0200 Subject: Typo fixes. --- website/features/SneakyThrows.html | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'website/features') diff --git a/website/features/SneakyThrows.html b/website/features/SneakyThrows.html index b5d3194a..ac3f1f4f 100644 --- a/website/features/SneakyThrows.html +++ b/website/features/SneakyThrows.html @@ -21,17 +21,17 @@ or otherwise modify the thrown checked exception; it simply fakes out the compiler. On the JVM (class file) level, all exceptions, checked or not, can be thrown regardless of the throws clause of your methods, which is why this works.

- CAREFUL: Unlike other lombok transformations, you need to put lombok.jar on your classpath when + CAREFUL: Unlike other lombok transformations, you need to put lombok.jar on your classpath when you run your program.

- Common use cases for when you want to opt out of the checked exception mechanism center around 2 situations:

  • -
      A needlessly strict interface, such as Runnable - whatever exception propagates out of your run() method, + Common use cases for when you want to opt out of the checked exception mechanism center around 2 situations:
        +
      • A needlessly strict interface, such as Runnable - whatever exception propagates out of your run() method, checked or not, it will be passed to the Thread's unhandled exception handler. Catching a checked exception and wrapping it - in some sort of RuntimeException is only obscuring the real cause of the issue.
      -
        An 'impossible' exception. For example, new String(someByteArray, "UTF-8"); declares that it can throw an + in some sort of RuntimeException is only obscuring the real cause of the issue. +
      • An 'impossible' exception. For example, new String(someByteArray, "UTF-8"); declares that it can throw an UnsupportedEncodingException but according to the JVM specification, UTF-8 must always be available. An UnsupportedEncodingException here is about as likely as a ClassNotFoundError when you use a String object, - and you don't catch those either!
      + and you don't catch those either!

    Be aware that it is impossible to catch sneakily thrown checked types directly, as javac will not let you write a catch block for an exception type that no method call in the try body declares as thrown. This problem is not relevant in either of the use cases listed -- cgit