<\/p>\n
I can’t get no satisfaction, I can’t get no satisfaction
\n‘Cause I try and I try and I try and I try<\/p>\n
(I Can’t Get No) Satisfaction – The Rolling Stones<\/span><\/p>\n It’s a controversial subject; searching Google for checked versus unchecked exceptions<\/a> reveals a lot of heated discussions both for and against Checked Exceptions. My view is similar. I can almost<\/em> see a situation where I would like to ensure that exceptions are dealt with in a certain way, but it doesn’t quite reach as far as using checked exceptions.<\/p>\n Noisy IDEs<\/strong><\/p>\n I think my issue is largely to do with the way that the IDEs (and compilers) deal with checked exceptions. The default Eclipse template for try \/ catch is to catch the exception and print the stack trace. This isn’t really handling<\/em> the exception, it’s ignoring it<\/em> (even if we’ve logged it). There is no way to know if this is an acceptable default without understanding the underlying code. Unfortunately, if we are leaving it as the default we probably don’t understand the underlying code (yet).<\/p>\n An alternative to Checked Exceptions<\/strong> Something that I’m thinking about (but haven’t had the need to implement yet), is the concept of an ExceptionHandler class. This is an ideal place for Java Generics to come into play. By coding in this way, we can provide sensible default actions, such as: \/\/ The Generic stuff has not been checked and is for illustration purposes. public class LogAndIgnoreExceptionHandler extends ExceptionHandler<T extends Exception> { This reduces the try \/ catch noise, gives us the compiler checking and type completion, and explicitly details the strategy that we are using for handling the exceptions for this part of code.<\/p>\n I’m open to someone showing me a really good use of checked exceptions, but for the time being, I won’t be using them.<\/p>\n","protected":false},"excerpt":{"rendered":" I can’t get no satisfaction, I can’t get no satisfaction ‘Cause I try and I try and I try and I try (I Can’t Get No) Satisfaction – The Rolling Stones Checked vs. Unchecked Exceptions It’s a controversial subject; searching Google for checked versus unchecked exceptions reveals a lot of heated discussions both for and […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[19,17,22,21],"_links":{"self":[{"href":"https:\/\/andypalmer.com\/wp-json\/wp\/v2\/posts\/13"}],"collection":[{"href":"https:\/\/andypalmer.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/andypalmer.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/andypalmer.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/andypalmer.com\/wp-json\/wp\/v2\/comments?post=13"}],"version-history":[{"count":3,"href":"https:\/\/andypalmer.com\/wp-json\/wp\/v2\/posts\/13\/revisions"}],"predecessor-version":[{"id":19,"href":"https:\/\/andypalmer.com\/wp-json\/wp\/v2\/posts\/13\/revisions\/19"}],"wp:attachment":[{"href":"https:\/\/andypalmer.com\/wp-json\/wp\/v2\/media?parent=13"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/andypalmer.com\/wp-json\/wp\/v2\/categories?post=13"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/andypalmer.com\/wp-json\/wp\/v2\/tags?post=13"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Checked vs. Unchecked Exceptions<\/h3>\n
\nCharles Lowell<\/a> has a particularly succinct (and possibly NSFW) view<\/a><\/p>\n
\nIn Eclipse, if a method throws a checked exception, then auto-fix suggests two options; “Surround with try\/catch” and “Add throws declaration to method”
\nI particularly have a problem with the second one. The further you get away from the source of the exception, the less likely you are to deal with it in a useful way. Not dealing with the exception is a reasonable option, but why does everyone in the call chain need to know about an exception that someone in the lower levels didn’t care enough about to handle?
\nUsing unchecked exceptions gives us the choice to handle or propagate the exception, without polluting the higher levels with knowledge of unhandled exceptions.<\/p>\n
\nOne of the nice things about checked exceptions is that they let you know the types of exception you can get. You get the IDE auto-completion and compiler checking.
\nA checked exception is essentially saying, “You might get this exception, and I insist<\/strong> that you deal with it in the way that you feel is most appropriate”
\nHow can we continue to do this, and at the same time prevent boiler-plate or unnecessary pollution?<\/p>\n
\nFor example:
\n
\npublic void someCodeThatMayThrowAFileNotFoundException(String fileName, ExceptionHandler<FileNotFoundException> exceptionHandler) {
\ntry {
\nopen(fileName); \/\/ throws FileNotFoundException
\n}
\ncatch (FileNotFoundException e) {
\nexceptionHandler.handleException(e);
\n}
\n}
\n<\/code><\/p>\n
\n<\/p>\n
\n\/\/ Let me know if I need to correct it :-)
\npublic class PropagatingExceptionHandler extends ExceptionHandler<T extends Exception> {
\npublic void handleException(T exception) {
\nthrow(exception);
\n}
\n}<\/p>\n
\npublic void handleException(T exception) {
\nexception.printStackTrace(); \/\/ or log4j equivalent
\n}
\n}
\n<\/code><\/p>\n