1

I am developing an API for a repository-like abstraction. I have two methods: 

// Throws an exception if object cannot be found
MyObj Get(MyIdType id);

// Returns false if object cannot be found; no exception
bool TryGet(out MyObj obj);

There is a requirement for a third variant: one that returns null if object cannot be found, and does not throw an exception. 

// Returns null if object cannot be found; no exception
MyObj ?????(MyIdType id);

I'm stuck as on what to name it. GetOrDefault has been ruled out as confusing. GetIfNotNull has been suggested, but also seems unclear. GetOrNull is the most promising so far.

Does anyone have any other suggestions, or know of any public APIs whose conventions I can follow?

afeygin
  • 1,213
  • 11
  • 26
  • 5
    Don't do it. Convince them that Get and TryGet are sufficient. Nulls are the devil. – TrueWill Nov 09 '11 at 20:22
  • 1
    I'd be more pissed that they want Get() to throw an exception if it's null. That's terrible. – Ricky Smith Nov 09 '11 at 20:25
  • 1
    @RickySmith it's not that the value exists and is null though, it's that a value doesn't exist with this key. In a `Dictionary` for example, this will throw an exception. – Connell Nov 09 '11 at 20:27
  • 2
    There are cases when it's ugly to use TryGet--lamba expressions become three lines instead of one. – afeygin Nov 09 '11 at 20:28
  • I agree with you on that one @afeygin, however I don't think most will. – Connell Nov 09 '11 at 20:31
  • It really makes no sense to throw an exception – IAbstract Nov 09 '11 at 20:36
  • @ConnellWatkins .. I fail to see the difference. It's obviously not exceptional to ask for a key that doesn't exist. If it's not exceptional, then it's not appropriate as an exception. Exception handling is one of the most costly functions of programming. – Ricky Smith Nov 10 '11 at 14:37
  • 1
    @RickySmith it depends on the object really, Microsoft obviously think that trying to get a key that doesn't exist from most of their list based objects is exceptional. Probably because it's good practice to call `Contains` or `ContainsKey` first. There is actually barely any cost of a `try catch` statement, only when an exception is thrown. – Connell Nov 10 '11 at 15:09
  • And there is a difference between a key with no value and no key at all imo – Connell Nov 10 '11 at 15:09
  • @ConnellWatkins I'd be happy to debate all the points you've made, but here is not the place. I apologize for bringing it up and detracting from the topic. – Ricky Smith Nov 10 '11 at 16:11
  • @RickySmith Pick up [Framework Design Guidelines](http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/0321545613) and read chapter 7: Exceptions. See what Microsoft's framework architects recommend. It's an eye-opener. – TrueWill Nov 10 '11 at 18:57

6 Answers6

3

I would opt to not have a Get method that behaves differently in two situations. Why not have the Get return null for all cases. Why throw an exception at all?

I would opt to leave it up to user code to throw an exception if a null value is returned, if required.

See this question for further guidance related to when to throw exceptions.

Community
  • 1
  • 1
steve_c
  • 6,235
  • 4
  • 32
  • 42
2

I'd go with GetOrDefault (as you suggested yourself) based on the LINQ extension method FirstOrDefault.

Maybe GetValue and GetValueOrDefault would sound better though.

Connell
  • 13,925
  • 11
  • 59
  • 92
  • That was my original suggestion, but my clients ruled it out. – afeygin Nov 09 '11 at 20:27
  • 1
    I hate clients... I'd convince them that those are the standard naming conventions used by Microsoft themselves (in LINQ). Pretty much all C# developers will know what this means without looking at a documentation, whereas any other method name you may need to document. – Connell Nov 09 '11 at 20:34
  • 1
    If the clients don't like your suggested method names, then I would suggest that the clients come up with their own method names. – phoog Nov 09 '11 at 20:35
  • @ConnellWatkins: unfortunately, without clients we don't have software to develop ;) - I do agree, though, that clients tend to make our jobs ...ummm ...challenging. – IAbstract Nov 09 '11 at 21:15
  • Indeed.. can't we all just develop for eachother? ;) – Connell Nov 09 '11 at 21:41
1

How about: GetOrDefault

The ...OrDefault is fairly standard in LINQ.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
0

In my opinion, you should stick with:

MyObj Get(MyIdType id);

Instead of throwing an exception here, simply return null. If there is a definite requirement to throw an exception or optionally, null, I would try:

MyObj Get (MyIdType id, bool ReturnDefault = false) // if .net 4

I don't particularly like this option - but sometimes requirements will override what we think feels right or natural.

IAbstract
  • 19,551
  • 15
  • 98
  • 146
0

You could try GetObjectOrReturnDefaultValue or, since you know it's a reference type GetObjectOrReturnNull. It's long and ugly, but it's not ambiguous.

phoog
  • 42,068
  • 6
  • 79
  • 117
0

I'd keep only bool TryGetXXXXX(out T value) variant on your interface and provide the rest as extension methods to it. It makes your interface itself very compact, but at the same time as useful as client wants.

Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179