| This seems a bit too unpragmatic. Would you also require the user to explicitly handle: * Index out of bounds on every array op * Integer overflow on every arithmetic op * OOM on every allocating op Maybe if you're writing an ironclad RTOS for a critical system without any good redundancy? Otherwise these are such pervasive operations that most have accepted that they're not worth handling everywhere they happen. Requiring that really dilutes the value/meaning of errors. Given this signature: fn do_thing() -> Result<T, E> There's a clear signal that there's legitimate error conditions that you probably want to think about today. If every function that accessed arrays, worked with integers, or allocated memory returned a Result, it would border on meaningless. It would be like if there was no Throwable/Exception distinction in Java. Everything would `throw Exception`, eliminating the value of even noting that something can fail. I think the only way such a system could be tolerable is if the language in question had really good dependent type support (but that wouldn't handle the OOM issue -- which you can't even reliably handle on some systems). Unwinding/crashing is valuable in a truly robust system, because it needs to handle crashes anyway. Might as well punt obscure problems to that level of the reliability system. (This is basically the basis of Erlang's task system, AFAIK) |
No. You have already diluted the meaning of errors, and you want them elevated to _your_ standard.
>Index out of bounds on every array op
These are removed if you build a rust program with --release.
>Integer overflow on every arithmetic op
Add the Wrapping class if you expect overflow. Overflow _shouldnt_ normally happen on an Integer operation. It is a hardware error when it happens, and can cause massive pain-in-ass bugs when it happens unexpectedly.
I'd rather get errors when it does happen, rather then find out 6 months into a production run.
>OOM on every allocating op
C does this also.