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. It's difficult to go through and normalise all these without breaking stuff. E.g., if you rethrow you make code that used to 'work' because the exception was only logged suddenly stop working. It's still worth doing but there are some risks if your users exercise code in a different way than you do in testing. 2011/3/28 Cédric Beust ♔ <[email protected]> > > > 2011/3/28 phil swenson <[email protected]> > >> Most of the time I can't do anything about an exception and checked >> exceptions force me to write boiler plate to deal with them - either giant >> throws clauses or wrap in another exception. So I argue the cost of having >> to deal with them in every case (checked) is greater than the cost of >> dealing with them in the rare case (unchecked). > > > The cost to you, the developer, yes, especially since Java's use of checked > exceptions in the libraries is pretty bad, as we all agreed. > > But the point is not to make *your* life easier, it's to produce robust > software. Following your reasoning, you would probably also want to ignore > error codes. > > Every time you end up having to think about an error case and actually > doing something about it (even if it's intentionally ignoring it because > it's harmless), the software you ship ends up being more robust. > > If I have to choose, I prefer to err on the side of robustness, even if it > costs me (the developer) some frustration. But I'm certainly always looking > for ways to make my life easier, as long as it doesn't negatively impact the > quality of the code I ship. > > -- > 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.
