Dave Cronin
SCJP, SCWCD, SCBCD
SCJP 1.4 * SCWCD 1.4 * SCBCD 1.3 * SCJA 1.0 * TOGAF 8
The problem with swallowing the exceptions are as you've noted: you lose information. The only positive here is that you have an easier time calling the method if you want to ignore the errors.Originally posted by Cheng Wei Lee:
Let's say I've a method that takes in a String representation of a date & then parses it to return a Timestamp object. In the midst of parsing, exceptions could be thrown (due to null string, invalid format, etc).
SCJP 1.4, SCDJWS , SCJA<br />I can do ALL things through CHRIST who strengthens me.
Well, they just named their methods differently. load(id) is my get(id) and get(id) is my find(id). Also, they have find() methods that take other query parameters. It's just different names for the methods. I still prefer mine as they're consistent, and I started using the pattern years before Hibernate existed.Originally posted by Pho Tek:
Incidentally Hibernate does the opposite of you.
[get(id)] returns null if the object with that id does not exist.
Originally posted by David Harkness:
I would handle it by letting the exceptions propagate and make the caller handle them explicitely. If I found I was writing a lot of code that called this method and swallowed the exceptions, I might write a parallel method that did just that.
SCJP 1.4 * SCWCD 1.4 * SCBCD 1.3 * SCJA 1.0 * TOGAF 8
I tend to favor unchecked exceptions where possible, limiting my use of checked exceptions to cases where I want it to be in the caller's face.Originally posted by Cheng Wei Lee:
In cases when the exception is an unchecked exception/error, will you still propagate it? Even if its a checked exception, when the information of why the exception occurs is non-important, would you still do likewise?
In general, encapsulate this inside the method. If you leave it outside, how long will it take for someone to call your method without checking their parameters? Or imagine how fun it will be to track down all calling code when you need to change how you check parameters.Where should we implement checks on parameters passed into a method? Should the checks be perform inside or outside of the method?
SCJP 1.4 * SCWCD 1.4 * SCBCD 1.3 * SCJA 1.0 * TOGAF 8
No, sometimes it's simply the right answer. What should Map.get() return when it doesn't find the given key? What should Person.getOldestBrother() return if the Person has no siblings?Originally posted by Arun Prasath:
Dont you think returning null in any method is a poor practice??
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Arun Prasath:
Guys,
Dont you think returning null in any method is a poor practice??
I generally not prefere returning null from any method.
If we need to return null, on what conditions should we need to??
can anyone explain/clarify me??
thanks
James Carman, President<br />Carman Consulting, Inc.
I completely agree. Heck, Sun even gives you Collections.EMPTY_LIST/SET/MAP.Originally posted by Stan James:
I'm using a vendor framework with a habit of returning null for not found on methods declared to return collections. It leads to a lot of null checking when an empty collection would have communicated the results just as well. I'd rather see the empty collection. Does that sound reasonable?
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |