|
Re: What's Your ShouldNeverHappenException?
|
Posted: Jan 19, 2007 12:07 PM
|
|
> > It's > > only because the compiler forced us to handle the > checked > > exception, and in that particular piece of code it > would > > mean that its Java platform has a bug. > > I can't agree with this. For one, whether the exception > was checked or not doesn't have any direct relationship > with whether the platform has a bug. Making this be the > determining factor is completely arbitrary. For example, > there was a bug in the initial version of 1.4 (IIRC) with > hotspot optimization that was causing NullPointerException > (or some other RuntimeException) to be thrown from code > that, per the JLS, could not throw such an exception. It > cannot be the case that only checked exceptions are > related to JVM failures. Your statement above, if taken > literally is demonstrably untrue.
The goal is not to test for and handle bugs in the platform. The program must assume that the platform is working properly, not try to handle bugs in it. The goal is to handle the checked exception, because the compiler forces the program to handle it. And in that particular situation, passing a constant or literal "UTF-8" as an encoding to a core Java API, that part of the program knows that if that one call throws an UnsupportedEncodingException then the platform has a bug. The program wasn't looking for a bug in the platform, but unfortunately the compiler forced it to handle a bug in the platform, so at that point all bets are off and throwing an Error is the best that code can do.
> Even so, if we take the code I posted above that accepts a > byte array and an encoding, it's clearly the case that > sometimes the encoding could be UTF-8 or any of the other > required encodings. But the way the code is structured, a > failure with UTF-8 would be handled as a RuntimeException, > not an Error. If you don't believe that code should > handle the required encodings specially and throw Errors > for these encodings, then in one case we are saying a > failure to encode with UTF-8 is an Error but in another > case we are saying it's an Exception. Why? The exact > same operation is be executed. The only difference is > whether we are hardcoding the encoding.
That difference is key. In the following code, an error in the platform (or bug in the code, e.g., "UTF8") is the only possibility, regardless of what's outside this code.
public static String encodeUrlInUtf8(URL url) { try { return URLEncoder.encode(url, "UTF-8"); } catch (UnsupportedEncodingException e) { throw new AssertionError(e); } }
If you widen the scope by making the encoding some kind of parameter, then the exception should be handled differently, because it's no longer so impossible. If it's a public library method, e.g., part of a Facade on the core API, then I would make the caller handle the checked exception:
public static String encodeUrlFacade(URL url, String encoding) throws UnsupportedEncodingException { return URLEncoder.encode(url, encoding); }
If it's a private method, then I might look at how it's called and still be able to assert the impossibility within the method. This has more risk of future bugs, though, because the locations of the encoding names are farther away from the assertion. So I would try to minimize the scope instead.
If the code is using a configuration parameter, I might throw a ConfigurationException extends RuntimeException. If a user typed the encoding name as input, I would validate it instead of throwing an exception (and then assert that the validated encoding is supported).
In any case, I would not go looking for platform bugs by writing code to check whether the encoding name String is one of those required to be supported by all Java platforms (and throwing an Error in that case). That would unnecessarily complicate the code. It would not be worth it.
The key issue here is what is impossible. What does impossible mean? What should the code assume and not try to handle? It depends on what scope the programmer is considering. The larger the scope, the more complexity and bugs.
|
|