Timeline for In Java, what are checked exceptions good for?
Current License: CC BY-SA 2.5
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 9, 2014 at 21:04 | comment | added | supercat | In any polymorphic language, there are going to be cases where some implementations of an abstract method will throw certain exceptions and other ones won't. There will also be cases where code will have good reason to believe that the implementations it is using are ones that will never throw. A good language should provide a concise means of saying "I am not expecting this method to throw any exceptions; any exceptions it does throw should be considered 'unexpected'", without requiring code to pretend to handle exceptions it can't deal with. | |
| Jun 2, 2014 at 9:54 | comment | added | Thomas W | Exception-handling best practice is "throw early, catch late". Actual handling should mostly be placed at the "business" or "request" level, since that is the level that failure isolates to. Checked exceptions instead force developers towards handling immediately, away from best practice. They also prevent FP functional programming/ abstraction of control flow, vastly increase boilerplate, and encourage miscoding. literatejava.com/exceptions/… | |
| Apr 30, 2014 at 10:37 | comment | added | palto | @TimWilliscroft I'm not sure what you mean here. What I've tried to argue is that you might not want to wrap exceptions because it gives you no added value. Without checked exceptions there would be no need for it. I originally made a comment because I felt quote like this: "If you're an amateur programmer (not programming for money), feel free to program in C# or some other language with no checked exceptions." and stuff like that doesn't belong in a good answer here. Wasn't my intention to start a discussion about how to work with checked exceptions. | |
| Apr 29, 2014 at 8:55 | comment | added | Tim Williscroft | @palto you could use a subclass of MyApplicationException like MyApplicationThirdPartyException so your toplevel handler, the one that interacts with the humans and says "Something went wrong, in a subsystem, engineers are investigating"; and then can send the stack trace and inner exception to your engineers. | |
| Apr 28, 2014 at 13:59 | comment | added | palto | @Giorgio Yeah but what about the exceptions that I cannot provide an error message because I don't know what went wrong? Not all libraries document all the cases where things might go wrong. For those cases you might have MyApplicationGenericException to wrap those to display a "Something went wrong but we don't know what, engineers are investigating" error message. All the useful information is in the stack trace. Wrapping the exception isn't at all useful so why do I even have to do it? Because of checked exceptions. | |
| Apr 27, 2014 at 15:49 | comment | added | Giorgio | @palto: If you do not want an IOException from a lower layer to bubble up to upper layers, then handling this exception and transforming it into something meaningful is part of the logic of the current layer. A file not found exception might be turned into an error message for the user. If you cannot do this, then the exception is part of the interface to the outside world: "things that can go wrong while I am executed and that you, the caller, should be aware of." | |
| Oct 11, 2012 at 18:32 | comment | added | palto | @ThomasEding Doing that will change the interface of everything above which reveals implementation details needlessly to every layer of the application. You can only do that if the exception is something you want to recover from and it makes sense in the interface. I don't want to add a IOException to my getPeople-method because some configuration file might be missing. It just doens't make sense. | |
| Oct 10, 2012 at 16:48 | comment | added | Thomas Eding | @palto: For what its worth, there is another option which avoids catching the exceptions: void foo () {...} becomes void foo () throws SomeException {...}. Isn't this what you really want? | |
| Oct 10, 2012 at 6:35 | comment | added | palto | @ThomasEding Java forces me to handle the exception where the method is called. It is very rare that I actually want to do something about it in the calling code and usually I want to bubble up the exception to the error handling layer of my application. I then have to remedy it with either wrapping up the exception in a Runtime exception or I have to create my own exception. Lazy programmers have a third option: just ignore it because I don't care. That way no one knows the error happened and the software has really odd bugs. That 3rd one doesn't happen with unchecked exceptions. | |
| Oct 9, 2012 at 18:56 | comment | added | Thomas Eding | @palto: Java forces you to consider the non-easy path. That's the big difference. For C#, you might say, "The exception is documented" and wash your hands of it. But programmers are error prone. They forget things. When I write code, I want to be 100% reminded of any cracks a compiler can inform me. | |
| Jun 12, 2012 at 13:58 | comment | added | palto | -1 You mixed a rant about bad programmers with checked exceptions. C# doesn't have checked exceptions but it doesn't mean it doesn't take corner cases and errors seriously. You can still handle exceptions in C#. C# just wont allow API designer to force the programmer to handle the exception in the calling layer. Not all errors are recoverable. A missing file might be because user typo'd it and user just has to change the name. Or it might be that someone deleted it and the program cannot work anymore so it has nothing else to do than crash. | |
| Jul 11, 2011 at 12:29 | comment | added | Sjoerd | I mostly agree with this rant. My major grip: there are other ways to deal with edge cases and unexpected conditions than checked exceptions (see other answers). Still, +1 for the very true 'The "happy path" for code is easy.' | |
| Dec 15, 2010 at 17:02 | comment | added | NimChimpsky | +1 "None of the edge cases ever worked. These days he does Python for an open source company. Nuff said." Classic | |
| Nov 18, 2010 at 16:50 | comment | added | Michael K | It is well written though; why downvote it? The point made here is that when in the context of checked exceptions, not checking them is lazy. Nothing wrong with that! | |
| Nov 16, 2010 at 3:22 | comment | added | Adam Lear♦ | Nice rant you got there. | |
| Nov 16, 2010 at 2:46 | history | answered | Tim Williscroft | CC BY-SA 2.5 |