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.
Conversation
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).
2
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.
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
(aside: I'm _personally_ pretty much ok with the costs of incremental dynamic propagation, but I'm also ok with the cost of uniform representation in generic code, green threads and even GARBAGE COLLECTION, so put me in the systems-programmer heresy bucket as needed)
1
2
Show replies