`params()` should `throw` when parameters aren't known yet

[tomayac]

Current implementations makes it impossible to know the actual values of the parameters reported on via params() before the model is downloaded. This means UI that would, for example, set a slider to the defaultTopK can only reliably do so after the model is downloaded.

The current implementation, however, returns made-up values that change after the true values are known, so UI would jump, which is against developer expectations. Instead, the params() function should throw (maybe an InvalidStateError) if the reported values can't be accurate yet to set developer expectations.

(Action item following crbug/441711146.)

[michaelwasserman]

Naive Q: WDYT about returning null (as Chrome Canary currently does), instead of throwing an error?

[tomayac]

Naive Q: WDYT about returning null (as Chrome Canary currently does), instead of throwing an error?

I'd likely want us to keep the door open to use null for things a given model doesn't support. Assume Browser X uses a model that supports topP, so we add it to the spec, but Browser Y uses a different model that doesn't support topP, so could report null. That's different from not having the values yet.