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.
