This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
- rename your method to "toRequiredFormat" or simply "format". Java supports method overloading, so you don't need to specify twice that this method takes a Calendar (once in the parameter list, once in the name).
- don't throw Exception; throw ParseException instead as that's the actual exception type being thrown.
- don't ever write code like this again:
You will loose all information on the message except the message. Better alternatives:
or even simpler
I'll show an example:
This won't compile under JDK 6 because you throw an exception but don't declare it. Under JDK 7/8 the compiler understands that the value of e is a CheckedException or a Runtime exception thus it's valid to throw it. The key is that e must be final otherwise it's value can change in the catch block.
Looks weird to me. It makes sense, as the compiler realizes the only values for e can be CheckedException or a RuntimeException, but that doesn't make it look better. It just looks like you're throwing Exception and therefore the method should declare to throw Exception. A lot of programmers will get confused when they read such code.
I'd prefer one of the other changes to catching exceptions that were planned: multicatch:
In the end, I agree with the final notes in this article: multicatch is awesome, final rethrow is weird.
I agree with you. Multi-catch is great and safe re-throw is nice. Multi-catch shall be used much more often by programmers than the re-throw functionality.
But the re-throw functionality is great for wrapping method calls and I assume that it will mainly be used by frameworks.