Skip to content

Discussion: Getting rid of 'null' and "error" in canonical-data? #905

@Vankog

Description

@Vankog

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.

E.g. @NobbZ said in #902:

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions