Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's generally better to highlight the existence of an error condition sooner rather than later.

Compile time is better than runtime, evaluation time is better than via explicit value inspection.

Non-signalling NaNs provide an easy way of distributing an invalid value widely throughout a program's data structures before it's discovered.

The only reason to go the other way, and have silent NaN propagation, is if they're expected to occur very frequently. For example, consider how awkward SQL would be if evaluating over null values triggered errors - the conditionality of expressions would need to become very elaborate.

Monadic approaches to errors (Maybe, Rust's Result, that conditionally apply a function to a value only if it's not an error) blur the line between these two. Because they rely on data flow, they feel a bit like non-signalling NaNs. OTOH, evaluation generally bubbles up using monadic return types, and errors bubble up too, just like exceptions - exceptions, and consistent, universal use of monadic return types, are isomorphic and can have the same evaluation characteristics.



> exceptions, and consistent, universal use of monadic return types, are isomorphic and can have the same evaluation characteristics.

I feel like there is a small but important difference. Encoding exceptions in monadic return types allows the type system to guarantee that all exceptions are handled, or at least considered by the programmer. That is a very strong guarantee, especially as you put up layers and layers of foreign libraries and abstractions.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: