Working with null

[ErikSchierboom]

How to handle null values? In general, they are widely used in C#, but are also a cause of pain due to the infamous null-reference exceptions. I think we should in general use exceptions when the input is invalid, as that is also what the .NET framework seems to do in most cases (int.Parse, etc.). We should use null when we want to indicate that no result could be found (e.g. when querying a collection for a value).

If we were to adopt this, that means that the phone-number tests should be using an exception instead of checking for null.

[robkeim]

@ErikSchierboom we started discussing this a bit in #360, I shouldn't have closed it before letting you chime in.

In #362 I discovered that there are actually three different ways the canonical data are handling "invalid/error" cases:

• null
• adding an error with description
• invalid value (such as -1 for numbers)

[ErikSchierboom]

Correct. For many exercises, the comments explicitly state that each track for themselves should decide how to treat invalid values. This makes sense as most functional languages would replace null with an option type, which you can't easily encode in JSON. Therefore, for each exercise we should determine what to do. The only thing the canonical data gives us is an indication if there is an error, an invalid value or a missing value. We as track maintainers should then decide how to encode it.

In #360 @jpreese said:

So my opinion is that the canonical-data should be the source of truth. Whatever is there, is what we render.

It would be great if we could do this, but unfortunately the canonical data is far from standarized and uses several ways to encode failure. In my opinion we should thus feel empowered to decide for ourselves what to do with failing input.

To make my point, the comments of the say exercise state:

"Here -1 is used as expected value to indicate that the",
"input value is out of the range described in the exercise."

-1 is thus used as the expected value, but it is merely an indicator of an out of range value. It doesn't actually state that -1 should be the expected return value.

[jpreese]

@ErikSchierboom so I have two approaches I would take on this then.

1. We update the canonical-data to be consistent. I think if the data isn't valid, an exception should be thrown. My gut says it would be better to be consistent. I assume the only reason why some canonical data is -1, others are null, others are exceptions is because its a community effort. Different contributors, different reviewers. It is a little heavy handed though.

2. If 1 isn't possible, I'm in the camp of throwing exceptions for everything that isn't valid input. I'm not a big fan of things like -1 and null representing failure. Even with the example of querying a collection and not finding anything, I'd rather see us returning an empty collection.

[ErikSchierboom]

@jpreese Good points, here's my take:

1. This is a hell of a job and probably not achieveable, due to the one language track considering null and error whereas another track might consider it a valid value.
2. Agreed. Unless @robkeim argues otherwise, let's just use exceptions for invalid input.

[robkeim]

@ErikSchierboom given the first one is going to be hard, going with only exceptions sounds good to me :)

[jpreese]

PR #371 resolves this. Thanks @robkeim !