|
I like to be consistent. Hence, my GetX(...) and FindX(...) always[1] do what I just described, no exception (sic!)
Vikram A Punathambekar wrote: FindTradeData(string tradeID) sounds silly.
In my book, that's not a valid reason to omit doing anything other than singing in falsetto... 
If I expect to find trade data with id tradeID in there, then I definitely consider it to be an error if it's not there, and I would therefore throw.
[1] Off the top of my head at 00.25 AM. My memory might fail, for obvious reasons. 
--
Time you enjoy wasting is not wasted time - Bertrand Russel
|
|
|
|
|
As a side note - I'm not hesitant to use GetOrCreateX(String id) methods if the object needs to manage things on it's own and the caller doesn't care if the X existed before the call or not.
--
Time you enjoy wasting is not wasted time - Bertrand Russel
|
|
|
|
|
I agree. Because it said you were expecting an object to be returned, then if it cant return one that's an exception. If it were a function that may or should probably return an object, then a null would be acceptable. More like a 'not found' (null) vs a 'couldn't load/create object for some other reason like corrupt data'.
|
|
|
|
|
I depends on the situation.
First choice is throw an Exception.
In some cases return an empty collection.
In other cases, return null.
|
|
|
|
|
Yes, it depends on how normal it is to find no result. If it is very very strange, I return an Exception. Otherwise it's usually null, or an empty collection in some cases.
|
|
|
|
|
me too. these days we use the exception handling application block, so i return null after the ExceptionPolicy.HandleException code. that way, if the exception is not rethrown, the method returns null.
|
|
|
|
|
I do 2 & 3, I almost never throw an exception, habit I guess, I certainly test and deal with the empty collection I just consider an exception a worst case scenario.
I have a favourite rant about programming by error, you know try writing to the database and if it throws an exception then there is something wrong, drop wing squawk loudly and run in circles
|
|
|
|
|
If I'm returning a Value type, then I can't return 'null'. If the method is for generics, than I'll use the 'default' keyword, but again, for Reference types, that will still translate to 'null'. At work in a lot a places in the code there is a result code and an out parameter. When returning a list of items, if there are no items then I may return an empty list instead of 'null'. So basically, it depends on the situation and what is being returned.
Should I be more consistent?
|
|
|
|
|
No. You shouldn't. This is the same way (or style?) I do it here.
|
|
|
|
|
I use some agreed upon impossible value if value type is in question, null if reference type and empty collection for collections.
Exception get thrown only if it is really an error, condition that is not checked by program or it comes from the database.
It is consistent regardless of treating different objects differently.
|
|
|
|
|
Much The Same - It depends upon what makes sense to return rather than entrapping myself with some dogmatic formula to which one must adhere.
For example, it is often much more sensible (fool-proof?) to return an empty String in a method that returns a String object, rather than a null - the results of which are therefore always printable. This avoids a later test of the return when something, even if blank, will always be required.
Will this confuse other potential users - isn't that what documentation is for ? ?
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"It's a sad state of affairs, indeed, when you start reading my tag lines for some sort of enlightenment. Sadder still, if that's where you need to find it." - Balboos HaGadol
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
