-
-
Notifications
You must be signed in to change notification settings - Fork 553
Description
It seems we found quite a deep topic to talk about.
There have been some concerns that show, that the canonical data should not have null
and the "expected": "error"
structures, because there are quite some inconsistent language concepts in the tracks.
null input,
In some languages not possible at all, and in my opinion, we should assume some safetynet in the early languages. Also those languages that constantly deal with null-errors should are free to add them as necessary.
I am not aware how many languages do not have a null-concept or something alike
Haskell, Rust, OCaml, Erlang, Elixir, maybe other.
Even those that do have a null value do treat it different in their idioms…
In go it seems as if
null
is often used synonym with the corresponding zero-value, especially when dealing with arrays, slices or strings.In other languages I've seen it as "please insert your default value here" when calling a function or the presence of a computation error/argument error when returned from a function.
So in other languages we do not even have strict typing to enforce an input string, shall we therefore do create a canonical test that throws when given an integer when strings are expected?
In some languages we could decide to even use the typesystem of the language to keep out invalid input and create a datatype
date Nucleotide = A | C | G | T
. Again this would make much of the tests obselete…Therefore, as I said, the canonical data should only contain a small limited set of test data which deals with correct input and expectations, while handling errornous input should be in the responsibility of the track.
Another reason why it should be in the tracks responsibility are different idioms and possibilities of error signaling. In go we have a multi-return and return errors as a value when they occur or nil if not. In Haskell, Rust, OCaml, Elixir, Erlang we have the habbit of returning
Maybe
,Either
,Result
,Some
,:ok
, and:error
tuples or whatnot. In Java and Ruby we throw or raise exceptions (which we do in erlang/elixir as well if we consider an error irrecoverable). In C we return a magic value which is documented (I hope) and also do sometimes even some global state which gives numerical and human readable info about the error.
also @stevejb71 said the same independently here: #895 (comment)
Some languages do not have exceptions, or would return an error type for invalid inputs.
So I have a feeling we have to purge these two concepts from the canonical data and from the schema.
I found "error" in the following exercises:
- bowling
- collatz-conjecture
- hamming
- nucleotide-count
- palindrome-products
- perfect-numbers
I found null
in the following exercises:
- word-search
- variable-length-quantity
- two-fer
- rna-transcription
- pov
- phone-number
- pascals-triangle
- forth
- flatten-array
- binary
- alphametics
- all-your-base