Sometimes tries to convince me this is what common lisp "conditions" are but i still haven't gotten around to learning how this works.
Conversation
Rust used to actually have conditions for stuff like IO errors, but having three different ways of doing error handling in one language was a bit much (results, panics, conditions). could probably elaborate…
2
2
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 ...
1
4
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™.
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).
2
Show replies