Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Code alternative

 
Sindhu Kodoor
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ,

I have a method that converts the given input to the required format,:



But "Calendar inputDate" is not the only input to be formatted, it can come in of datatype "Date" or of "String", how do I do that?please suggest
 
Raymond Tong
Ranch Hand
Posts: 255
2
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
method overloading
 
Rob Spoor
Sheriff
Pie
Posts: 20529
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Wouter Oet
Saloon Keeper
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Then make it this:
Because then in JDK 7 (8?) the safe re-throw concept will kick in.
 
Matthew Brown
Bartender
Posts: 4567
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wouter Oet wrote:Because then in JDK 7 (8?) the safe re-throw concept will kick in.

Interesting - I've not heard of that. I did a quick search, but didn't find anything very specific. Do you have any good references that will expain what that involves?
 
Wouter Oet
Saloon Keeper
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Rob Spoor
Sheriff
Pie
Posts: 20529
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Wouter Oet
Saloon Keeper
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic