A programming language idea: no static code, explicit caller context (Kite)
Marconi
soldate at gmail.com
Wed Apr 29 21:23:15 UTC 2026
Thinking more about it, I believe `caller` may be a much better
fit for resource authority than for error handling.
For allocation, filesystem access, logging, I/O, etc., the model
feels natural: the callee should not silently decide policies, so
it asks the caller for authority.
But for errors, the caller is not always the right entity to
understand what happened. The immediate caller may have less
context than the callee, and the top-level caller cannot
reasonably know every possible low-level failure.
So I’m reconsidering the idea of `caller.error(...)`.
A better direction may be to keep errors as a language-level flow
mechanism, closer to V’s `or` style:
config = parse(input) or {
return ConfigLoadFailed(err)
}
That way, the callee still classifies what failed, each layer can
translate the error into its own domain, and the caller decides
policy only when it actually has enough context.
So perhaps:
caller = authority for resources/effects
error flow = handled by the language
This seems cleaner than forcing all error handling through
`caller`.
More information about the Digitalmars-d
mailing list