As promised, I have attempted to rewrite my original function |move|
with a mechanism that would let us define issue-handling policies. This
mechanism is inspired by both the current thread and the previous thread
on exceptions, a few months ago.
So far, the result is not too convincing yet, but
This code seems wrong... what if an error occurs as part of the call to
`copy()`, for example?
As a kind of experience report, I have been using `result` types for
those parts of the compiler where errors must be recoverable rather than
just being reported to the user and papered over. I
* The system _must_ not prevent, some day, developers from calling Rust
from JavaScript.
* The system _must_ not prevent, some day, developers from calling
JavaScript from Rust.
I'm not aware of any precedents for calling out of or into Javascript, in
any language. What specific constraints
In general it seems there are three classes of errors
- globally unrecoverable (just call `fail`)
- locally unrecoverable (return a `resultX,Y` type)
- recoverable (pass in handler or error reporter)
Globally unrecoverable means that the whole task cannot continue (this is
On Tue, May 29, 2012 at 7:57 AM, Niko Matsakis n...@alum.mit.edu wrote:
In general it seems there are three classes of errors
- globally unrecoverable (just call `fail`)
- locally unrecoverable (return a `resultX,Y` type)
- recoverable (pass in handler or error reporter)
If you have
