Some suggestions:
- 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.