Nothing cols fixes

[Jolanrensen]

This PR contains a handful of fixes and optimizations regarding Nothing(?) in column types:

• Fixes DataFrame with Nothing? column is detected as FormattedFrame<*>? in notebooks #1546 and adds a helpful note to colsOf to prevent future confusion
• DataColumn.empty() created a Unit-typed column. I have no idea why, I made it Nothing, which better represents that emptyCol.get(0): Nothing will always throw an exception. Added DataColumn.emptyOf<T>() if you need a specifically typed empty column.
• #1546 also discovered that exceptions in update provided little info, so I added UpdateException for this.
• While inspecting Column DataCollector for null-filled or empty columns, I rewrote ::class-logic to typeOf's (for efficiency), and added redundancy checks:
  • (If the data collector should produce a Nothing column, it can only do that if it has no values; so the resulting column must be empty)
  • (if the data collector should produce a Nothing? column, it can only do that if all its values are null)

I also checked usages of colsOf() querying for nullable types to see if similar issues like #1546 existed. Fortunately, in most cases, including null-filled columns are not an issue! All statistics functions simply skip nulls, for instance.

There are some unfortunate cases, like:

dataFrameOf(
    "a" to columnOf(1, 2, 3, null),
    "b" to columnOf(null, null, null, null),
    "c" to columnOf(7, 3, 2, 65),
).fillNulls { colsOf<Int?>() }.with { 0 }

which throw java.lang.IllegalArgumentException: Can not add value of class kotlin.Int to column of type kotlin.Nothing?. Value = 0 because column b: Nothing? is included by colsOf<Int?>(). However, hopefully, the note to add .filter { !it.allNulls() } is found :). Alternatively, we could decide to add an argument colsOf<Int?>(exactType = true) in the future.

[koperagen]

Better to add this supertype only if you have example of code that triggers this in compiler plugin

[Jolanrensen]

Ah, that might be difficult, as it most often relies on runtime information. (besides maybe update {}.with { error() }). I thought we now preferred to use the DataFrameError type for any new exception we create

[koperagen]

I think about it as a way to opt-in reporting warnings for exceptions, that we know for sure make sense for user. In theory we could report any exception. DataFrameError will help us to validate them first

[Jolanrensen]

soo... DataFrameWarning? ;P

[koperagen]

Could be

[koperagen]

We have two operations that use empty: concatImpl and getColumn. Please see if they can be affected by this change. Otherwise it's quite neat

[Jolanrensen]

seems concat fails on dataframes without rows, but not because of Nothing columns, but because it uses ::class reflection in createColumnGuessingType(), interesting

[Jolanrensen]

fixed it in the next commit :)