Yeah, this is what's finally bringing me over to Rust. I don't want to write code by Rust's constraints, but maybe I can think of it like Rust's memory constraints being "these are the module boundary constraints" and use cheatz to violate the constraints in-module.
Conversation
Incidentally, I am still waiting for a language that has a way of agreeing how exceptional conditions are handled across module boundaries. I don't believe exception handling is good enough
2
3
What I want is a standard idiom where actual errors like "invalid parameters" and exceptional-but-expected conditions like "file not found" are handled within the same mechanism, yet the mechanism understands one is lighter-weight and must be easier to do casually than the other.
1
3
Sometimes tries to convince me this is what common lisp "conditions" are but i still haven't gotten around to learning how this works.
2
3
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
I’ve seen a potent formulation of them as algebraic effect handler analogues / duals, if that helps. Ref
1
2
Yeah, an algebraic effect solution would be pretty sweet - but you also may want to track error provenance (ie. stack trace), at least in debug builds. Not sure if that is possible for effects/handlers. Also, can you get the same level of performance using that?
I think so if you don't unwind the stack and supply a multi-short continuation. Instead, you can allow explicit resume/fork/abort in handlers. Then the common case (resume) is basically the cost of a function call.
1
1
Yeah unfortunately even the cost of fluid-binding a handler and releasing it on scope boundaries is considered intolerable by many users, never mind the cost of invocation (same complaint surfaces around SJ/LJ and SEH, there's just no pleasing people!)
1
1
Show replies