tag:blogger.com,1999:blog-741750605858169835.post4033209297213186531..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: Checked Exceptions (#bijava)Stephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger30125tag:blogger.com,1999:blog-741750605858169835.post-68566473696410604202019-03-30T18:50:03.680+00:002019-03-30T18:50:03.680+00:00Checked exceptions are meaningful only in the Java...Checked exceptions are meaningful only in the Java compiler -- the JVM does not distinguish between checked/unchecked exceptions. Therefore Oracle could have it both ways, they could provide a compiler argument to control the treatment of checked exceptions e.g.:<br><br /> <i>-Xchecked-exception-handling: (neutral|throws|strict)</i><br /><br />I'm not sure if Oracle has considered this strategy; I've only read about the either/or proposition.<br /><br />Regardless, until that time you can use the <a href="http://manifold.systems/docs.html#checked-exception-suppression" rel="nofollow">Manifold</a> compiler plugin to achieve the same goal: <b>neutralize checked exceptions</b>. With the <i>exceptions</i> plugin option enabled checked exceptions behave exactly like unchecked exceptions. No more try/catch/wrap/rethrow boilerplate nonsense, no more unintentional exception swallowing, no more lambda usage conflicts.Scotthttps://www.blogger.com/profile/12061224875037688699noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-16521348169749159732015-12-13T22:07:19.054+00:002015-12-13T22:07:19.054+00:00I'm a fan of the CheckedException for the scen...I'm a fan of the CheckedException for the scenario when no matter how much (or how well) you test the code to be executed, it can still fail. Obvious examples are when a disk fills up before the write finishes, a network outage, and a hardware failure.<br /><br />Although I'm not always excited to be forced to handle a checked exception, one of the reasons I program in Java is because checked exceptions are there. I'll admit that Sun was not very clear on documenting when to use a Checked vs Unchecked exceptions they have always said an unchecked exception should be regarded as a programming error and it really holds true.Anonymoushttps://www.blogger.com/profile/04838123109787722323noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-77707854821534038692015-06-03T12:57:41.080+01:002015-06-03T12:57:41.080+01:00I"ve programmed in both Java and C#. There w...I"ve programmed in both Java and C#. There was a time when I developed a C# application, an exception was thrown caused the entire application to crash. I then fixed it by catching this exception and just return a null value and the called checks if it returns null then do nothing. <br /><br />If C# had checked exception, I would be able to find this at compile time, capture it and return null. The crash would probably never occur at runtime. Imagine if this was not found in testing but in a production environment. That was the time I really thought having a checked exception would be useful sometimes. However, I do agree with the point where it caused pain for the API users if it is used incorrectly. I also think practically you probably can never "recover" from an exception, the benefit of checked exception is just give you a chance to deal with it at compile time rather in the runtime.<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-6002832661010268362014-11-19T22:54:09.153+00:002014-11-19T22:54:09.153+00:00checked exceptions can be a (literal) life saver i...checked exceptions can be a (literal) life saver in safety-critical software.Anonymoushttps://www.blogger.com/profile/16284479427313424578noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-64287584952134355972014-05-31T04:29:22.128+01:002014-05-31T04:29:22.128+01:00Good article! Checked exceptions were originally ...Good article! Checked exceptions were originally intended to highlight contingencies, but were always incompatible with best-practice "throw early, catch late" exception-handling/ and FP functional programming constructs. <br /><br />Instead of being being used solely for contingencies, though, they became used for all sorts of unrecoverable low-level systemic failure. This was the fundamental mis-use in Java libraries, which saw them become such a problem.<br /><br />See: http://literatejava.com/uncategorized/checked-exceptions-javas-biggest-mistake/Thomas Whttps://www.blogger.com/profile/06287256406464617259noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-58515442786558785662010-10-01T09:10:03.000+01:002010-10-01T09:10:03.000+01:00I will keep it short:
- This post is not an analys...I will keep it short:<br />- This post is not an analysis but rather an opinion; <br />- I agree with many of the previous posters that checked exceptions are misused rather than unneeded and that one can do as much harm with unchecked exception;<br />- Stating "If you are still using or advocating checked exceptions then I'm afraid you skill set is 5 to 10 years out of date." sounds to me rather arrogant and, in the light of what you showed after, a clear contradiction.<br /><br />AlessandroAlessandronoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-87238608268052566992010-09-30T15:50:49.000+01:002010-09-30T15:50:49.000+01:00I am struck by the symmetries between the suggesti...I am struck by the symmetries between the suggestions of nullable types and checked exceptions.<br /><br />Each is a case of asking the compiler to keep track of additional information to enforce better safety. Each is a case in which documentation alone would likely prove insufficient.<br /><br />The argument for nullable types is that it would reduce boilerplate a little and cut down on innate, unguarded errors by a large measure. The argument against checked exceptions is that it would reduce boilerplate a lot, even if it increases the number of unguarded errors a little.<br /><br />Mr. Colebourne rejected "Maybe" as a potential solution for nullable types, because of the functional mindset that entails and the verbosity it entails. I wonder, though, if the consequence of eliminating checked exceptions would be the creation of many "Maybe" classes. That is, in the case of an exception which should be handled by the calling method, methods would have to be defined with a return type that encapsulates the exception, the return value, and perhaps also various descriptions of the returned state. (Leading to oft-ignored return values for methods that would otherwise return void.)<br /><br />Perhaps, though, this "returned Maybe" construction would be rare enough in practice that it would reduce boilerplate overall and be worth it. Or perhaps a better solution would be include annotations like "@ignore(ExceptionClass)" and "@rethrow(ExceptionClass, AsExceptionClass)"; together, those two annotations would handle much of the boilerplate.<br /><br />So far, I'm mostly disagreeing with the people asserting that it's not worth having the discussion. It's clearly a trade-off with consequences each direction.JamesGnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-3487644998351563062010-09-29T21:39:41.000+01:002010-09-29T21:39:41.000+01:00Thanks for your thoughts in an area I've given...Thanks for your thoughts in an area I've given much thought over the years. Two things occur to me about what you've written. Firstly the case where programmers misuse checked exceptions doesn't seem like a good reason to call that part of the language flawed; it almost never happens in the large codebase I work on, and when it does, usually by lazy programmers, then they are educated as to how important considering these details are and they realise they need to apply more thought to their work. Secondly I agree with Robert above, where a library (such as SpringJdbc) chooses to use unchecked exceptions exclusively that fact that it is a library surely comes into making that decision, thus this is not really a justfication for using unchecked exceptions exclusively across the board. My own opinion is that a strategy consisting of a mix of both types of exception is a reasonable and effective strategy, the important point being that the strategy used in an application is just that, a considered strategy used consistently throughout the application. That said, a strategy including exclusive use of unchecked exceptions is also a reasonable approach, the one I'm highly dubious of (and have seen) is exclusive use of checked exceptions, now that is something I do strongly disagree with.Antony Warnernoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-37161523479240935692010-09-29T14:46:47.000+01:002010-09-29T14:46:47.000+01:00IMHO, the original problem is separation of concer...IMHO, the original problem is separation of concerns.<br /><br />Let's take an example. There are, for example, general purpose packages (~ use context agnostic packages), like the Java "Collection" package. When mixing such packages with other API with specific exceptions, the heaven would be that those specific exceptions would have no impact on the use of the general purpose packages, with an ideal separation of concerns. But such ideal do not exist (yet?)<br /><br />Then, 2 solutions appear, following an all-or-nothing approach:<br />- all: force always developers to deal explicitly with exceptions<br />- nothing: make exceptions silent, that is, unchecked.<br /><br /><br />The ideal would be to associate exceptions with a kind of namespace. According to that idea, Java classes interested into some events may declare themselves interested into exceptions with given namespaces, that is, may declare they are ok to deal with exceptions of some given namespaces; then, for such classes, those exceptions, possibly raised by called methods, would become checked exceptions, while other exceptions would be unchecked. <br /><br />At first glance, it looks like doable, but the need may not worth the effort, while there is a simplest solution: making all exceptions silent!Dominique De Vitohttp://www.jroller.com/dmdevitonoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-39396263774108178992010-09-29T04:01:07.000+01:002010-09-29T04:01:07.000+01:00Very interesting discussion, Stephen.
Couldn'...Very interesting discussion, Stephen.<br /><br />Couldn't resist putting in my 2c. (Also posted to my blog).<br /><br />It seems to me that declaring a checked exception involves making three claims:<br />1. You can't programmatically prevent this exception from occurring. You must recover from the exception rather than prevent it.<br />2. You're so likely to forget to handle this case, and it is likely enough and serious enough to occur, that I'm going to force you to decide how you're going to deal with it right now ...<br />3. ... but it's not so terminal or abnormal that most applications shouldn't try to catch it. (That's Error.)<br /><br />Item 1 makes me think they should be rare. Prevention is better than cure, but checked exceptions require you to write cure.<br /><br />But I'm not sure that "rare" is the same as "non-existant"William Billingsleyhttp://wbillingsley.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-22167194310398645052010-09-28T10:40:23.000+01:002010-09-28T10:40:23.000+01:00I agree with you that checked exception are the pa...I agree with you that checked exception are the pain in the ass of every Java developer.<br />But I think that most of the problems they present is related the ackward syntax, and not in the check mechanism itself, which could be useful in some cases.<br />That's why I was happy to hear from Mark Reinhold that some improvements are coming on that side, but not more.Fabrizio Gianneschihttp://jroller.com/bitognoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-57550666528449795002010-09-27T20:30:34.000+01:002010-09-27T20:30:34.000+01:00"What did you have in mind for recovering fro..."What did you have in mind for recovering from UserAlreadyExistsException?"<br /><br />Well, it would make sense to inform the user that the name selected for the new account is already taken... and to ask him to choose another. Basically what every registration form does.<br /><br />You will want to handle this exception specifically. Just showing a dialog saying: "Oops, something went wrong: username not available." is dumb. It is clearly a recoverable, common business error that is part of the normal flow.<br /><br />"Checked exceptions should be rare, but they should be allowed because it can be useful in some cases, such as operating with low level operations. Such as File Systems, Networking, etc."<br /><br />No, that's exactly where you should *not* use them. We don't want to have to catch DiskFull and OutOfMemory and NetworkDown exceptions every other method. Those should be runtime exceptions that we only catch in a catch-all, log-and-give-up block.<br /><br />It's recoverable business errors that are solvable (and mostly caused by) the user that should be checked exceptions... if any.<br /><br />I have a love hate affair with checked exceptions. When used wisely I think there is a strong case for them as they make the exceptions a part of the method signature just like the return value. It's all the over-use that spoiled it.<br /><br />So maybe runtime exceptions should be the default and checked exceptions should be the exceptions?Stijn de Witthttp://StijnDeWitt.wordpress.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-41234933231406764192010-09-27T15:29:47.000+01:002010-09-27T15:29:47.000+01:00You can't do static analysis of exception hand...You can't do static analysis of exception handling in applications where the exception generating code is dynamically loaded (and unknown at analysis time). For example if using a plugable file system, you may wish to handle exceptions like FileNotFound or FileLocked, but without throws statements on the interfaces the static analysis can't help.<br />Further, without checked exceptions, those throws lists will tend to be inaccurate (those lazy developers).<br /><br />In short checked exceptions are intended to support static analysis of exception handling whether in javac or elsewhere. Without them, exceptions become a purely dynamic feature. Many will be happy with that --- they never handle specifc exceptions anyway, but just have a generic "it failed" handler at the top of the stack.Mark Thorntonnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-63154038995111667452010-09-27T09:37:10.000+01:002010-09-27T09:37:10.000+01:00I'm wondering - is removing checked exceptions...I'm wondering - is removing checked exceptions really backwards incompatible change?<br /><br />Let's assume that we just corrected javac that it does not require any catch statements ever. You can still use 'throws' clause, for every kind of Throwable, as documentation tool. You can try to catch any exception, regardless if it was declared in throws clause in any of the method calls inside the block.<br /><br />Is there any current code which would be broken by those changes? As no jvm change is required, all old class files should also run in new java.Artur Biesiadowskinoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-57891909923361125872010-09-26T23:48:52.000+01:002010-09-26T23:48:52.000+01:00Checked exceptions were useful in the absence of s...Checked exceptions were useful in the absence of static-analysis tools that can provide the same (or better) information.<br /><br />One might conclude from a reading of the JLS that all exceptions are ideally checked, but certain were excluded because they would detract from program readability or because their inclusion was questionable since they cannot or should not be handled. Not only does this have the compiler performing an analysis task (one among many) that, arguably, is conflating its purpose, but checked exceptions have several drawbacks, including detracting from program readability and encouraging a variety of anti-patterns.<br /><br />Checked exceptions is a feature that should be removed from the language syntax and moved from compilation to static analysis.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-21312883913165682682010-09-26T03:45:32.000+01:002010-09-26T03:45:32.000+01:00If a few people understand checked exceptions, why...If a few people understand checked exceptions, why do we have to remove it completely? That doesn't quite make sense. <br /><br />I believe that checked exceptions should be rare, but they should be allowed because it can be useful in some cases, such as operating with low level operations.<br /><br />Such as File Systems, Networking, etc.Mohamed Mansourhttp://www.mohamedmansour.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-81696309901433182542010-09-24T09:43:01.000+01:002010-09-24T09:43:01.000+01:00Writing code that is interoperable with Java and d...Writing code that is interoperable with Java and does not have checked exceptions is proven to work with Scala. (There is some fine print like annotating checked exception). In the end checked exceptions are a compiler hack.<br /><br />But removing checked exceptions might be to fast. The goal of the checked exception could be changed from forcing everyone to handle checked exceptions to supporting the developers that would like to handle the exceptions.<br /><br />If you have a language that supports pattern matching the compiler may give you a warning when a pattern matching is not exhaustive. The same could be supported for exceptions. Basically, leave the checked exceptions (semantics) as they are now. If a developer wants to catch exceptions he can state if you would like to catch all (checked or run-time) exceptions. The compiler can then warn if you did not handle all checked exceptions. <br /><br />try{<br />[..]<br />}<br />exhaustive //compiler warning if other exceptions than E1 and E2 are thrown<br />catch (E1) { }<br />catch (E2) { }<br /><br />The distinction between fatal (throwable), handleable (checked) and programming errors (run-time) is still useful.Thomas Junghttp://theyougen.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-6971591294999664692010-09-24T09:07:03.000+01:002010-09-24T09:07:03.000+01:00Hi Stephen,
I'm a (lazy) developer and I cat...Hi Stephen, <br /><br />I'm a (lazy) developer and I catch checked exceptions only to call a global exceptions handler (to report myself the error basically).<br /><br />If you remove checked exception, how can I define that exception handler globally ?Davidnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-79187012261854329432010-09-24T04:36:52.000+01:002010-09-24T04:36:52.000+01:00I posted the original blog entry to the java posse...I posted the original blog entry to the java posse google group and it turned into a giant checked exception debate. I of course am in the checked exceptions are retarded camp. Checked exceptions lead to bad code, it's that simple.<br /><br />Here is the link: http://groups.google.com/group/javaposse/browse_thread/thread/6ab9c4feb095435ephil swensonnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-86900733907808053612010-09-24T02:18:21.000+01:002010-09-24T02:18:21.000+01:00@Karl - ok, what did you have in mind for recoveri...@Karl - ok, what did you have in mind for recovering from UserAlreadyExistsException? I'd like to build out the entire example.Squirrels Ewerhttp://squirrelsewer.blogspot.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-52979230202681867792010-09-24T00:26:10.000+01:002010-09-24T00:26:10.000+01:00@Lawrence: Oh yes, UnsupportedEncodingException is...@Lawrence: Oh yes, UnsupportedEncodingException is a top-notch killjoy! <br /><br />@Squirrels Ewer: Think of a service API for the creation of user accounts. A UserAlreadyExistsException is a good candidate for a checked exception, since it can be handled properly. Nobody can tell in advance if the chosen username already exists, so you have to deal with it anyway.<br /><br />Rule of thumb: Checked if truly recoverable under regular conditions. Unchecked for all stuff that will end up as stack-trace in the server logs or as "Woah dude, something bad happended!"-dialog at the client. <br /><br />I know, this distinction remains vague and squishy. But in many cases it's a simple question of common sense. I have never seen any piece of Java software which seriously attempts to recover from a TransformerConfigurationException (beyond logging, wrapping and rethrowing, until a final UncaughtExceptionHandler does some brute-force error handling).Karl Peterbauernoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-28626369006768439612010-09-23T21:45:23.000+01:002010-09-23T21:45:23.000+01:00Can a checked exception fan out there provide an e...Can a checked exception fan out there provide an example of checked exceptions as they should be used? Just a short sample where you think checked exceptions really shine.Squirrels Ewerhttp://squirrelsewer.blogspot.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-64392909697610782652010-09-23T21:28:58.000+01:002010-09-23T21:28:58.000+01:00Speaking of Java enhancements (though not a backwa...Speaking of Java enhancements (though not a backward-incompatible one), I'd like:<br /><br /> if (one.!equals(two))<br /><br />be sugar for:<br /><br /> if (!one.equals(two))<br /><br />It reads better that way, and it's usually after typing "one" that I realize that I want not-equals. (Obviously for any boolean method, not just equals.)Lawrence Kestelootnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-41449489902178501892010-09-23T21:09:36.000+01:002010-09-23T21:09:36.000+01:00This sounds like you are falling to the lowest com...This sounds like you are falling to the lowest common denominator. Your logic appears to be that many developers misuse checked exception, therefor it should not be available to any developers. <br /><br />Is Java to be a language of choice for the best developers or the "lazy" ones?<br /><br />There are many features of Java which are mis-used or very poorly understood, e.g. floating point arithmatic. By the same logic we should remove this too. e.g. I recently had a candidate of 10 years IT experience tell me that -0.0 might have a round error. :PPeter Lawreynoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-83363620991687153172010-09-23T20:41:58.000+01:002010-09-23T20:41:58.000+01:00Karl, the one that annoys me the most is Unsupport...Karl, the one that annoys me the most is UnsupportedEncodingException when I'm passing in a hard-coded encoding name that's guaranteed to exist by the language ("UTF-8", "ASCII", etc.). I have to catch and re-throw as an Error.Lawrence Kestelootnoreply@blogger.com