But I don't _want_ to surround the statement with a try/catch block!

Question

I'm writing a program that uses java.net.URLDecoder.decode(String value, String encoding). Apparently, this method might throw an UnsupportedEncodingException, which I get. But I'm just passing "UTF-8" as the encoding. It won't throw that exception.

I could just surround the darn thing with a catch block that does nothing, but then in whatever freak case does cause the exception to be thrown, I won't find out about it. I do not want to create a big chain of throws UnsupportedEncodingException up to the top of my program, either.

What can I do here? Why am I forced to deal with some Exceptions, while others (e.g. IllegalArgumentException, NullPointerException) I'm allowed to ignore?

On a side note, the exceptions you're allowed to ignore are generally the exceptions that you _should_ ignore up until your catch-all handler for logging and graceful termination. Usage exceptions like IllegalArgumentException and NullPointerException indicate bugs and unstable program state. On the other hand, checked exception types are not necessarily fatal, so the philosophy behind checked exceptions requires that you explicitly clarify either how you want to handle it (even if that means asserting a failure) or whether you're leaving that responsibility up to the caller. — Dan Bryant, Nov 02 '10 at 20:20
@DanBryant: This is one of those classic cases. 99.99% of callers pass a constant here. The exception really can't happen. — Joshua, Dec 12 '16 at 22:51

score 25 · Accepted Answer · edited May 23 '17 at 12:24

25

I think you need a better grasp of checked exceptions and their purpose in general, but that is for another question and answer. In this case what you do is:

 try {
      //etc.
 } catch (UnsupportedEncodingException e) {
      throw new RuntimeException(e.getMessage(), e);
 }

edited May 23 '17 at 12:24

Community

1
1

answered Nov 02 '10 at 18:01

Yishai

90,445
31
189
263

3

+1. But on a side note: This assumes you consider an UnsupportedEncodingException to be crucial to the current Thread. Otherwise if your program is outputting logging information you could always Log it with an appropriate level instead. – Valchris Nov 02 '10 at 18:04
2

+1 My code is filled with this time of code. It's tedious but it's necessary. Much better than letting the exceptions bubble up the stack. – peter.murray.rust Nov 02 '10 at 18:07
8

This solution is good, because it makes explicit that the checked exception UnsupportedEncodingException should be interpreted as a bug (and therefore fatal) if it's thrown in this context. – Dan Bryant Nov 02 '10 at 18:20
7

Nitpicking here: The JVM spec explicitly demands support for UTF8. If it doesn't support UTF8, it's no JVM. Therefore, `AssertionError` is a better fit than the plain `RuntimeException`. – Barend Nov 02 '10 at 19:58

score 4 · Answer 2 · edited May 16 '15 at 00:24

4

There are two types of exception.

CheckedException: It make you force to use try-catch or throw to the top of program.
UncheckedException: You can bypass.. It would raise on runtime only

I just accept the fact that Java designed that way to make the program less error-prone.

edited May 16 '15 at 00:24

Moak

12,596
27
111
166

answered Nov 02 '10 at 18:03

exiter2000

548
5
14

1

What's a proun? Is this some sort of reference to District 9? ;) – Amir Afghani Nov 02 '10 at 18:04
Just to add, all exceptions in java are checked, unless they extend RuntimeException. – Jeremy Nov 02 '10 at 18:13

score 2 · Answer 3 · answered Nov 02 '10 at 18:04

If it bothers you that much, then you can always use the deprecated, single-argument form of URLDecoder.decode(). This doesn't take the encoding parameter, and doesn't throw the checked exception.

Of course, this method is deprecated for a reason - its behaviour depends on the JVM's default encoding, which can vary depending on the operating environment. But if you know that your environment doesn't vary, this may not matter. There's also the risk that the method will be removed in future versions of Java, but no deprecated items have yet to be removed, and I doubt that will ever happen.

score 2 · Answer 4 · answered Nov 02 '10 at 22:35

Some people wrap RuntimeException to avoid checked exceptions. However in your case you know this exception shouldn't happen. To my mind this is an assertion.

try { 
     //etc. 
} catch (UnsupportedEncodingException e) { 
     throw new AssertionError(e); 
}

Another way to rethrow a checked exception without wrapping it is to throw it as if it were an unchecked exception. You can try this.

try { 
     // throws a checked exception
} catch (Exception e) { 
     Thread.currentThread().stop(e);
}

score 1 · Answer 5 · answered Nov 02 '10 at 18:22

The UnsupportedEncodingException is a checked exception by the URLDecoder.decode method and you must either catch it or specify that your method throws it.

public static String decodeUTF8String(String s) throws UnsupportedEncodingException 
{
    return java.net.URLDecoder.decode(s, "UTF-8"); 
}

A good lesson on exceptions

But I don't _want_ to surround the statement with a try/catch block!

5 Answers5