On Wed, May 23, 2012 at 2:47 PM, David Rajchenbach-Teller < dtel...@mozilla.com> 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. > > As a whole, this looks very good to me, I just have one quick question: > * 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). > Could you explain what you mean by this ? I suppose this is a direct jab at the horror that is errno and more in the direction of being able to "throw" anything (possibly at the condition it implements a given interface) ? > * 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? > > Cheers, > David > > On 5/22/12 4:56 AM, Bennie Kloosteman wrote: > > Are exceptions a good model for systems programming ? > > > > - legacy C programs cant call you without a wrapper which translates > > all possible exceptions > > - unwinding a stack is probably not a good idea in a kernel or when > > you transition into protected/user mode.( I know of very few kernels > > that use exceptions ). > > - Its not just legacy , Winrt uses C++ classes but returns error codes > > tor low level APIs. > > > > However its very nice for user programs . These days these different > > worlds works quite well , c libs which Is mainly used for system > > programming don't use them and C++ apps are more user programs and > > they do , C++ calls C , C rarely calls C++. Obviously if you write a > > kernel or shared library you cannot use exceptions if c programs > > call your code and there is a lot of c out there.... While not really > > an issue for the language ( just dont use exceptions) it means a > > standard lib that throws an exception would be a pain for such work > > and you would need a different standard lib , which is an issue . > > > > BTW could Rust use tasks as a substitute for exception scopes ? Tasks > > have error bubbling , hiding , "stack unwinding" , throw ( fail) and > > should have integrated logging . You could put a sugar syntax around > > it but it would still work when being called by c. Also with tasks > > you can cancel or do timeouts giving asynronous exceptions which are > > really needed ( eg in most systems cancel a long running task is very > > anoying very long pause). and which most trivial exception > > implementations don't do ..Not sure if this is the right way but there > > seems a lot of overlap and it would work with C and systems > > programming,. > > > > Ben > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev@mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > -- > David Rajchenbach-Teller, PhD > Performance Team, Mozilla > > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
