On 12-10-23 06:36 AM, Benjamin Striegel wrote:
> Thanks, this is very informative. I also have a few questions, so I
> apologize in advance if I betray my ignorance.
>
> The TLS key boilerplate would be rather unfortunate if it was forced to
> be in both the API provider and the API consumer, would it be possible
> to stick it in the io mod and then do
The boilerplate will eventually get absorbed into an item macro. And in
any case, yes, it should be declared in the IO module itself. Both the
TLS key and the Condition. That was a .. presentation mistake in my example.
> I'm also unsure as to why missing_file_key needs to be a function at
> all, nor why Condition needs to be a single-element struct.
In order for the .trap method to _exist_. It's an impl on a type. We
could also write:
do Condition::trap(missing_file_key, || handler).in {
}
it's pretty much synonymous, I just like the way it reads a bit better
as an impl. Could be implemented on an enum too, but there's no real
benefit either way.
> Lastly, is it expected that rustdoc will learn to detect every time that
> .raise() is called on a Condition? How will users of an API be expected
> to discover all the possible signals that are available to be trapped
> from any given function?
We might be able to do some decoration with attributes to help rustdoc
out here, but in general it's a transitive thing (not just conditions in
this function, but conditions in any called-functions) so not going to
be easy to bound without hoisting it up into the type system, which
we're not intending to do.
Part of the ... let's say "philosophy" of error handling in Rust is that
one ought to accept the possibility that any task can fail in ways you
can't foresee, though: OS signals, termination from other tasks, out of
memory, array overrun, etc. etc. The task boundary exists for this
reason: to protect you from having to know or be-able-to-recover from
all forms of failure.
So while I agree it'll be nice if we can present conditions via docs to
some extent, and possibly some extreme forms of extended static checks,
I don't expect "exhaustive handling" to really ever be the norm on this
sort of thing.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
