▲ | nyeah 2 days ago | |||||||||||||
NaN is not necessarily an error. It might be fine. It depends on what you're doing with it. If NaN is invalid input for the next step, then sure why not treat it as an error? But that's a design decision not an imperative that everybody must follow. (I picture Mel Brooks' 15 commandments, #11-15, that fell and broke. This is not like that.) | ||||||||||||||
▲ | kccqzy 2 days ago | parent | next [-] | |||||||||||||
Yes it is totally fine. I've seen code basically treating NaN as missing data as opposed to std::optional<double> or equivalent in your language. NaN propagates so this works like using such types as a monad. | ||||||||||||||
▲ | BlackFly 2 days ago | parent | prev [-] | |||||||||||||
Sure, not every runtime type error needs to panic your application, nor even panic a request handler, nor even result in a failed handling. That doesn't mean you didn't encounter an error though. Error doesn't mean fatal. The design decision isn't, "Was this a type error?" but, "What do I need to do about this type error?" | ||||||||||||||
|