On 05/23/2012 05:47 AM, David Rajchenbach-Teller wrote:
Actually, one of the conclusions of our previous discussion is that
Java/C++/ML-style exceptions are probably not what we want for Rust. I
seem to remember that we also concluded that using failures as
exceptions was probably not the right course.
Hence this new thread :)
Let me put together what I believe are a few desirable qualities of an
"issue management system". For the moment, let's not wonder whether that
system is a language feature, a library or a coding guideline.
* The system _must_ not prevent developers from calling C code from Rust.
* The system _must_ not prevent developers from passing a pointer to a
Rust function to C code that will call back to it.
* 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.
* Issues _must_ not be restricted to integers (or to one single type).
* The default behavior in case of untreated issue _should_ be to
gracefully kill the task or the application.
* Whenever an untreated issue kills a task/application, it _should_
produces a report usable by the developer for fixing the issue.
* It _should_ be possible to deactivate that killing behavior. There
_may_ be limitations.
* It _should_ be possible to deactivate that killing behavior
conditionally (i.e. only for some errors).
* The system _should_ eventually have a low runtime cost – in
particular, the case in which no killing happens should be very fast.
Do we agree on this base?
These points sound sensible to me.
-Brian
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
