0

Given a bool validation function that takes an argument and returns true or false based on argument's compliance to some internal rules:

if the argument is null, should the function:

  • return false
  • return true
  • do neither and simply raise a ArgumentNullException

I would tend to believe the best practice is to raise the exception. I am however curious to hear others experience on the subject.

Given the sole choice of a bool, I am personally tempted to return false, but could see benefits in returning true also, based on the context of the function's usage. A null string for instance could be interpreted as empty and may be considered valid.

Are there best practice guidelines for this specific situation? I am looking for a guideline, like ones found in books like Code Complete.

Does it always need to be a case by case?

Louis
  • 705
  • 10
  • 18
  • This belongs on programmers.SE – theMayer Nov 27 '14 at 20:47
  • `FileNotFound` or `42` – leppie Nov 27 '14 at 20:47
  • Your question is very unclear - it is completely reasonable to have `null` as valid value... So there is no way to answer for all possible validation functions how they should behave. Note that in current form question will likely be off-topic as opinion based on all StackExchange sites, not just SO. While looking at it you may read on "null object pattern" for possible alternative approaches to original problem of null values. – Alexei Levenkov Nov 28 '14 at 04:25
  • Thanks Alexei. I thought my question was valid, simple and fairly clear. I also hoped it would be welcomed, to help others, as I did ran into this problem countless times. I realize now it was probably too broad and subjective and regret asking it. – Louis Nov 28 '14 at 13:51

2 Answers2

1

I don't think there's a general best practice, it will depend on the semantics.

Does it make sense to receive null? If so, return true or false based on what makes more sense, e.g. an hypothetical isAlphaNumericString(String) returning true when passed null is most likely nonsensical, but returning false may make sense.

But if it makes no sense to receive null, then a null marks a problem in the call, raise an exception to enforce the caller to make sense.

outlyer
  • 3,933
  • 2
  • 14
  • 18
  • Thanks outlyer for your answer. As you point out, this is more a case by case, but I ran into this situation often and was curious to hear others take on it. – Louis Nov 27 '14 at 21:12
-1

As I interpret your question, your input-variable space is determined by each value the variable can take augmented by a null state. In SQL for example, this corresponds to some type, say INTEGER and NULL. In C++, for example, it corresponds to something like boost::optional<int> in which null means "uninitialized".

Now, I think the cleanest solution is to augment the result-space as well with null. This is also the choice both examples above follow (or at least commonly follow). For example, if a scalar function such as LENGTH() or also a comparison operator in SQL takes a NULL argument, it usually also returns NULL.

More on the theoretical side, this implements somthing like an isomorphism from the null-subspace in definition space to the null-subspace in result space (and the same holds for the complement, i.e. the non-null space). The advantage of this is tha you do not have to reinterpret your original function at all.

davidhigh
  • 14,652
  • 2
  • 44
  • 75
  • This question is about Java. The only two possible values for a Java boolean type are true and false; it's not possible to return null. – user2752467 Nov 27 '14 at 20:57
  • @JustinLardinois unless it's a `Boolean`. But, although it can be inferred as Java, the OP doesn't mention any particular language. – outlyer Nov 27 '14 at 20:57
  • @JustinLardinois: so, the generic "argument" mentioned by the OP can be `null`, but not the special argument `boolean`. So so ... – davidhigh Nov 27 '14 at 20:59
  • I realize this should have been asked on Programmers SE as pointed out by theMayer. I wanted to leave it language free, but I am coding in C#. – Louis Nov 27 '14 at 21:00
  • @Louis: my answer is language free. For specific examples, of course, you need to choose one language. – davidhigh Nov 27 '14 at 21:01
  • @JustinLardinois: regarding Java, see also here: [Class Optional](https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html) – davidhigh Nov 27 '14 at 21:02
  • @davidhigh: Thanks for suggesting the augmented result-space. I was however looking for a best practice rule when 'true' or 'false' are the only possible values. Again, a broad question, but I will get better with those. – Louis Nov 27 '14 at 21:17
  • @Louis: it's your choice, but I don't think that is consistent. Why actually can the variable be `null` at all? Why not throw an exception when it becomes `null` and use your "normal" exception-free function instead? On the other hand, once you allow for `null`s, why shouldn't it be allowed also to return `null`s? You'd need to augment *each* function like this in order to be consistent... – davidhigh Nov 27 '14 at 21:21