Find should return null when item isn't found, instead of throwing an exception

[maynardflies]

Refer to #51

[scale-tone]

The typical convention for "Find" is to return default(T) when the item doesn't exis

Well, it depends, actually :) E.g. Entity Framework does return null, yes. While ADO.Net throws.

Because of that ambiguity and because this definitely looks like a breaking change, I would propose to introduce separate methods (e.g. TryFind() and TryFindAsync()) instead.

[maynardflies]

Apologies if I'm looking at the wrong place, but from what I'm reading, DataViews in ADO.NET don't throw, they also return null or -1 for rows that aren't found, my source is here: https://msdn.microsoft.com/en-us/library/yth8t382(v=vs.100).aspx

can you let me know which ADO.NET construct you're referring to if I'm lokoing at the wrong one?

[maynardflies]

Sorry, you included the link to your source in your comment :P

however, in your link, it says:

Return Value Type: System.Data.DataRow A DataRow object that contains the primary key values specified; otherwise a null value if the primary key value does not exist in the DataRowCollection.

However I think you're looking at the part that says

Exception	Condition
IndexOutOfRangeException	No row corresponds to that index value.

if you look at the source for the method, it looks like this

    private DataRow FindRow(DataKey key, object[] values) {
            Index index = GetIndex(NewIndexDesc(key));
            Range range = index.FindRecords(values);
            if (range.IsNull)
                return null;
            return recordManager[index.GetRecord(range.Min)];
        }

Following that code through, it looks like the only time it actually throws that exception is when the key is null or empty, rather than when the node isn't found. You can replicate my rabbit hole here

[scale-tone]

Anyway, I would prefer not to do a breaking change and introduce separate methods with that new behavior. Would you agree?

[maynardflies]

I certainly understand the desire not to introduce a breaking change for this, that being said though it would preferably only be temporary until we DO make that change to eliminate technical debt and bring it in line with the framework conventions underlying it. In my opinion I'd rather make the breaking change and advise the community about it rather than creating a stop-gap, but interested in your suggestions

[maynardflies]

Hi Konstantin, do you have a final decision on this? if you dont want to implement it this way, feel free to tweak it as you see fit, but we should get it closed out when we can. Thanks!

[scale-tone]

Hi, sorry, I was having a vacation :)

I still think, that a new separate method is better. Don't really like breaking changes, particularly without clear reasons.

[maynardflies]

Personally I think the reason is clear; the typical convention for .NET is for Find to return null, not an exception. However, it's your project, so if you want to change it then feel free, just want to get this closed out