[galaxyLogic]

> you can't differentiate between an actual empty array or an error

Empty array in this pattern does not represent an error. It represents the fact that no values you asked for can be found. It is like querying a database. It is not an error if your query finds no values.

The calling code that receives the empty array might decide it is an error or that it is not. And of course you can always throw an error, that can be done with the "throw" keyword.

Getting rid of using nulls by using arrays instead is not about handling errors, but about preventing errors, by changing the semantics of your functions slightly so they never need to return null.

[valenterry]

You can just replace "error" in my post with "not there" and the meaning stays the same though.

[galaxyLogic]

No not really. If every result is an Array then such an array can contain an empty array and then it itself is NOT an empty array. It's all about how you specify the semantic contract of your function.

You can say a result was found and that result is an array, possibly an empty array. Or that no result was found which is indicated by returning TOP-LEVEL empty array.

[valenterry]

Well yeah, that's why I said:

> Or, you actually have to use nested arrays to describe that the result might be an error or an array. But now you have to deal with an array which might contain... zero errors or even multiple ones.

In other words: now you have Array<Array<?>>

And now it is only convention that the outer array must only have 0 or 1 elements. But there is no guarantee and the compiler won't help you since it cannot know. That's why this is the inferior approach compared to turning it around and making it so that null can be mapped and flattened.