I think this discussion has come to a solid point: it's more about the process than tech. BTW, we already have UnsupportedOperationException, which I often use in my own code as a way get something half-baked to compile and mark the place to come back to later.
But the big lesson I think is that the state of exceptions in Java poses a few problems and there is no single completely satisfactory solution. Instead, there are a few ways we can go: modify the language with or without backward compatibility, twist compiler's arm with trickery. Decisions also have to be made about what the desired world is to look like: abandon checked exceptions, clean up API and keep and perpetuate checked exceptions in the "right way", loosen the leash and give the developer a bit more freedom to choose how dictatorial they want API contracts to be with exception handling (warnings, ignore declarations, etc.). Clearly some soul searching is in order. But what's interesting here is that there is no obviously right way to go because of the way great variety of circumstances of how exceptions are used and the legacy questions. All we really "know" is: * exceptions in general appear preferred in the Java community over Either constructs * there is a lot to be gained by more careful future exception class hierarchy design * much detriment was done by default exception (non-)handling in IDE's * no matter what happens, there are many gray areas, where it is difficult for an API author to foresee whether the context of its use is best served with immediate handling or bubbling up of exceptions Alexey ________________________________ From: Cédric Beust ♔ <[email protected]> To: Ricky Clarkson <[email protected]> Cc: [email protected]; phil swenson <[email protected]>; Phil <[email protected]> Sent: Mon, March 28, 2011 5:18:45 PM Subject: Re: [The Java Posse] Re: How to deal with CheckedExceptions On Mon, Mar 28, 2011 at 2:09 PM, Ricky Clarkson <[email protected]> wrote: The problem is that when you're coding 'the happy path' you might not want to think about all the error cases, but to get the happy path compiling and running you need to add the try..catches (yes, throws works too, but not in all cases - Runnable, etc.) and you're doing that before you've considered error-handling properly. > > >The symptom on reasonably large codebases is that you end up with whatever the >coder/IDE inserts for catch blocks by default, ranging from nothing (sometimes >with // this can't happen), through logging (bonus points if each catch uses a >different logging framework), exiting the program and rethrowing as runtime. That's a very good point against checked exceptions. I have been claiming that the strength of checked exceptions is that they force you to think about errors very early on, but I think it's very fair to argue that sometimes, they do so "too soon". What if you don't have a reporting/logging/error structure in place? What if you know the error needs to be handled but you're not sure how just yet? I don't have a very good answer to that, although I suspect the right answer lies more in the area of "process" than in software engineering practices. By process, I mean things such as code reviews, or a NotYetImplementedException, or a stub that will do the error handling at some point in the future, or other ideas... -- Cédric -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
