• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Code alternative

 
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 258
2
IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
method overloading
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Bartender
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Then make it this:
Because then in JDK 7 (8?) the safe re-throw concept will kick in.
 
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Bartender
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Bartender
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic