I can answer this the short way and the long way. Short: yes, Rust had a condition system (at one point language-supported, at a later point library-only) and we took it out due to underuse. Longer: I'm a fair bit more skeptical of conditions now than I was a decade ago ...
Conversation
Aside from subsuming panic-like unwinding, they provide fluid-bound ignore-error / substitute-value strategies, which are both good sometimes, but also easy to mimic through dedicated error-handling arguments to possibly-signalling functions.
1
1
And the way they're "better" than that -- one fluid-bound handler covering many signallers at arbitrary distance -- is also the way they're "worse", by not being at all clear about exactly which signaller you're handling.
1
1
They have this intrinsic tradeoff in common with unwind-based throw/catch handlers-at-a-distance: the very economy of handling you're aiming for is in tradeoff with precision in deciding what to do. Generic connection-closed error? From _where_?
2
So combine that with the fact that explicit recovery-strategy arguments (eg. utf8-decode substitution) are a suitable standin, _and_ the fact that other strategies (eg. collect or defer errors) typically reify the error, the residual utility seems modest at best.
2
1
Fascinating, I'd not considered how often simpler recovery strategies are sufficient. Given an expressive condition system 'hammer', everything looks like a nail.
1
1
I think the Smalltalk condition system is more approachable than CL, as its terminology is closer to popular PLs.
Edit-and-continue with multiple resumable exceptions is a lovely way to work IME. Requires a lot of tooling support though, with major overheads (by Rust standards).
1
1
Sounds quite similar to something you could get with algebraic effects/handlers. Is there a link between them? If I accepted the overhead I would want to go with the more general idea - ie. effects.
1
I still wish we could figure out an almost zero-cost effect/handler system - I want this for the Next Systems Language™.
1
1
I think there's something deeply tradeoff-y in there, cost-wise: dynamic control is inherently undecidable so at some level you either incrementally adjust the coupling during runtime (pervasive tax), or defer reconstructing the coupling until it's needed (slow invocation).
1
1
Indeed. I wonder if it could be compiled away statically, but reified if you only if you actually need it (say, for async scheduling).
I want effects when I'm writing tests so I don't need to use mocks or dependency injection, but I want my prod code to be compiled down to what I would write in a procedural language.
1
But then I guess we want reified effects when doing exception handling, so we will need to make a tradeoff there. `Result` passing isn't free, but I don't want an alternative to be any worse than that.
1
Show replies
This will also inevitably get into whole-program vs. separate-compilation questions, what your commitments looks like at an ABI level (doubly complex when you have any kind of type extension or encapsulation).
2