4 ms·
> It’s by such misadventure that the working F# programmer soon realizes that any function could still potentially throw. That's your problem right there. "In
by rectang 7y ago
> It’s by such misadventure that the working F# programmer soon realizes that any function could still potentially throw.
That's your problem right there. "Invisible control flow", as Joe Duffy puts it.
http://joeduffyblog.com/2016/02/07/the-error-model/#unchecked-exceptions http://joeduffyblog.com/2016/02/07/the-error-model/#unchecke...
What's needed are two distinct error mechanisms: panic/abandonment for unrecoverable errors (which can happen at any time), and then for recoverable errors, either checked exceptions in some flavor (including Swift and Midori's untyped `throws`) or Result types.
Once you eliminate invisible control flow, you're no longer "better off using Exceptions".
- goto11 7y agoBut then the failed code which decides if the error is recoverable, not the part of the code doing the recovering.
- rectang 7y agoYes! We shouldn't expect downstream to wrap every array access which could be out of bounds in a "try" block. We shouldn't expect downstream to wrap every division operation in order to catch potential divide by zero errors. Those should be fatal errors, catchable only at a very coarse-grained level, because once they occur the program state is potentially compromised in a way which the programmer did not plan for. The library author gets to decide whether a potential failure mode should expose a recovery API.