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? 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 > [email protected] > https://mail.mozilla.org/listinfo/rust-dev -- David Rajchenbach-Teller, PhD Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
