tag:blogger.com,1999:blog-2892701085334104567.post3027175776332855861..comments2023-06-01T16:21:48.497+05:30Comments on Death By Code: Problems with Checked Exception in JavaArnab Biswashttp://www.blogger.com/profile/04713075170640671243noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-2892701085334104567.post-61267438492221586782021-10-20T12:09:52.322+05:302021-10-20T12:09:52.322+05:30I cannot thank you enough for the blog.Thanks Agai...I cannot thank you enough for the blog.Thanks Again. Keep writing.<br /><a href="https://www.kitsonlinetrainings.com/course/sap-abap-online-training-course" rel="nofollow">SAP ABAP training</a><br /><a href="https://www.kitsonlinetrainings.com/course/sap-abap-online-training-course" rel="nofollow">SAP ABAP online training in hyderabad</a>KITS Technologieshttps://www.blogger.com/profile/01255736173821596606noreply@blogger.comtag:blogger.com,1999:blog-2892701085334104567.post-89199264854569946092012-02-12T14:53:48.636+05:302012-02-12T14:53:48.636+05:30I agree that some time boiler plate code for check...I agree that some time boiler plate code for checked exception make code unreadable but there are many techniques to get around this problem one of them is <a href="http://javarevisited.blogspot.com/2011/12/checked-vs-unchecked-exception-in-java.html" rel="nofollow">wrapping Checked Exception into uncheckedException</a>, spring has used it quite well and converted many JDBC related exception into DataAccessException.Also Java7 new feature <a href="http://javarevisited.blogspot.com/2011/07/jdk7-multi-cache-block-example-tutorial.html" rel="nofollow">multiple exception in one cache block</a> and <a href="http://javarevisited.blogspot.com/2011/09/arm-automatic-resource-management-in.html" rel="nofollow">Automatic resource management provide some relief</a>.javin paulhttps://www.blogger.com/profile/15028902221295732276noreply@blogger.comtag:blogger.com,1999:blog-2892701085334104567.post-55255533060916434632011-07-08T15:10:10.937+05:302011-07-08T15:10:10.937+05:30> With the usage of ONLY Unchecked Exception (i...> With the usage of ONLY Unchecked Exception (i.e. by avoiding checked exceptions), problems 1, 2, 3 can really be addressed. <br /><br />All it really does is ignore the problem. Its a cross your fingers and hope the documentation is up to date and being read and actioned by all developers everytime there is a change.<br /><br />There are APIs in the core java which throw undocumented unchecked exceptions. The only way to know what they are is to read all the code to find them.<br /><br />IMHO, a catch block should handle the exception. Otherwise, the catch block is pointless and shouldn't be there.Peter Lawreyhttps://www.blogger.com/profile/17982030676088168612noreply@blogger.comtag:blogger.com,1999:blog-2892701085334104567.post-66340698794882306942011-07-08T14:55:47.008+05:302011-07-08T14:55:47.008+05:30An edge case point, but Throwable and its sub clas...An edge case point, but Throwable and its sub classes are all checked except Error and RuntimeException and their subclasses.<br /><br />i.e. you can create your own branch of Throwable and it will be checked. That doesn't make it a good idea. ;)Peter Lawreyhttps://www.blogger.com/profile/17982030676088168612noreply@blogger.comtag:blogger.com,1999:blog-2892701085334104567.post-59713071768431589512010-12-06T23:32:20.386+05:302010-12-06T23:32:20.386+05:30Thinking of checked exceptions as a problem indica...Thinking of checked exceptions as a problem indicates a failure to recognize what software development involves. Getting the software to produce proper results when given proper inputs is naturally the most important aspect of software development. But the next most important aspect of writing software is detecting and handling problems.<br /><br />Thinking that checked exceptions are a problem (and that handling them isn't possible or important), indicates that the developer has failed to realize what their second-most-important responsibility is.Brian Gilstraphttps://www.blogger.com/profile/11799840454645440786noreply@blogger.comtag:blogger.com,1999:blog-2892701085334104567.post-1666851250174070452010-12-05T20:22:23.282+05:302010-12-05T20:22:23.282+05:30Java 7 introduces multi catch throw which can appe...Java 7 introduces multi catch throw which can appease us as we generally handles all excetion in same way.<br />catch it, log it, throw it isnt it :)Souravhttps://www.blogger.com/profile/06746410302862646012noreply@blogger.comtag:blogger.com,1999:blog-2892701085334104567.post-89051392982021215602010-12-05T20:18:57.196+05:302010-12-05T20:18:57.196+05:30I have some comments on the above points mentioned...I have some comments on the above points mentioned, just to put my own perceptions and present my perspectives on the mentioned points<br /><br />1. It is true that whether an exception is recoverable or not depends on the situation/context when/where the exception had occurred.<br />This is the same reason, I believe, all RuntimeExceptions are unchecked. Because, technically speking, all java methods are capable of throwing different types of RuntimeException, isn't it? Because compiler does not know beforehand that a method cannot throw NullPointerException during runtime. So if java language is designed in that way think of the horror of putting catch blocks everywhere for this type of trivial exceptions.<br /><br />Instead they had come up with different idea. They clearly divided the demarcation betwenn erswhile undivided exception family. Below is the excerpt from JLS:<br /><br />"The runtime exception classes (RuntimeException and its subclasses) are exempted from compile-time checking because, in the judgment of the designers of the Java programming language, having to declare such exceptions would not aid significantly in establishing the correctness of programs. Many of the operations and constructs of the Java programming language can result in runtime exceptions. The information available to a compiler, and the level of analysis the compiler performs, are usually not sufficient to establish that such run-time exceptions cannot occur, even though this may be obvious to the programmer. Requiring such exception classes to be declared would simply be an irritation to programmers."<br /><br />Along with that they had introducued innumerable no. of RuntimeExceptions which can be readily used in different trivial situations.<br /><br />If you notice, nowhere it is mentioned the samantics/usage guidelines whe/where to use checked/unchecked exceptions. This is a trend provided by early proponents of the language.<br /><br />As an API author, I can only visualize what "extra" exceptional situations one might face if they use my API.(other than trivial NullPointerException :)). Like java.io.* packages introduce a generic IOException and its specialized subtypes which may come up when one uses some class/methods from that package. My perspective of an API is that it is a self-contained piece. Its a mere one building block rather than a building itself. So it exposes the 'handle with care' tag. I mean, which are the extra burden API user has to carry to use this. Its upto API author's perspective which he/she thinks needs to be thrown.<br /><br />But an application is made of thousands of such building blocks and typically composed of different layers. A lowest layer can throw FileNotFoundException every now and then but a comparatively higher layer , which typically has some broader view, may decide whether its a really exceptional scenario or not. <br />For example if you have ever seen Windoes event viewer, you will find hell lot of error/warning events that have been continuosuly happening in system. But for only few thing the OS cribs and pops Send/Don't send box.<br /><br />Depending on this they can throw it as it is, can wrap it in more application specific checked exception etc.<br /><br />For example, <br />a) The java.util.Enumeration.nextElement() method throws NoSuchElementException (FYI its a RunTimeException) if no elements found. It is , you can say, an exception thrown from lowest layer. But application developer/API user can put hasNextElementCheck() method before calling nextElement() call and can safely use. Similar analogy can be used for checked exceptionsSouravhttps://www.blogger.com/profile/06746410302862646012noreply@blogger.com