On 12-06-01 5:47 AM, David Rajchenbach-Teller wrote:
My main concern is that we would end up with a Rust used in-the-wild without either guidelines, library or mechanism for handling non-fatal issues.
Yeah. We'll have to pin down a technique and use it widely through the stdlib when we're comfortable with it. Similar to the matter of classes / objects / ifaces. We're still doing some late-stage design work here. Shouldn't be much longer, a few months and we'll have to pick something and commit to it.
I will keep using "issue" for the moment instead of error/exception/failure/... to avoid projecting too much semantics.
Ok.
* Function `handler::try` prepares for execution a block (let's call it the "action block") and lets the developer registers closures to handle various issue cases that may arise during the execution of that action block.
Yes. Might not be necessary to write in this form, but it scopes the push/pop of new handlers. This was just a sketch and I'm sure there are some conceptual / implementation bugs we'd need to iron out to make it just right.
* Function `?.handle(some_issue)` registers a block to handle one specific kind of issue.
Yes.
* Execution of the handler block takes place locally, without any stack unwinding.
Yes.
* Execution of the action block starts at the end of the chain of `?.handle(...)`. Is there a way to do this in Rust or does this require the addition of some kind of terminator?
Not sure I understand. The handler that gets run is the head of a list held in a task-local variable indexed by the constant in question (a hack: every constant has a unique address in the process, so is effectively a key you can use as per-process global unique value). Different constants refer to different handler lists, hence have no relationship. The .handle(...){...}.handle(...){...} chain is just pushing new entries on multiple handler lists simultaneously so they all get popped off at the same time when the try{...} block completes.
* A call to `signal` gives a chance to other issue handlers to execute. Do I understand correctly that this actually somehow pops the issue handler to avoid cycles?
It'll have to do so, yes.
* I also have the impression that a call to `signal` also performs some form of non-local return. Am I right?
No. It just picks the head of the handler list, call that H, then shifts the task-local handler list down by one so H can call outer handlers, then invokes H.
By the way, if I understand correctly, I believe that type name `handler<...>` is a little counter-intuitive.
Ok. Other suggestions welcome.
I will reply once I am sure that I understand the example :)
Please do follow up with further questions. If you want to drop by IRC and do some interactive Q&A that's also likely to help. I want to make sure we develop something here that at least *conceptually* sits well with everyone; it's a larger question whether it feels good in practice.
-Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
