On 11/18/11 8:45 PM, Graydon Hoare wrote: > Woah woah, I'm arriving late here. > > We *have* exceptions. They're called 'failure'. The only point about > them is that you can't catch them. For a couple reasons:
I feel that there is a little misunderstanding. If you do not mind, I would like to contextualize a little our conversation. Let's start with a little safety vocabulary, not specifically related to Rust. It is quite common to have two distinct words: "exceptions" for exceptional but expected behavior – that you typically want to catch – and "failures" for issues that are beyond the control of the developer and can at best be contained by shutting down a system and relaunch it. To attain a high level of safety, having a manner of dealing with both it is a Good Thing (tm). Fortunately, these two concepts mostly map to your points 1. or 2.: > [...] > - Philosophically, catching means either one of two things: > > 1. You know exactly what the failure means and an exact, transparent > recovery mode. For this we recommend simply modeling the recovery > mode you want for expected-but-rare circumstances as arguments > passed *into* the callee, and handled at the site of > circumstance. Think of how O_CREAT and O_TRUNC work in ::open. > We have these wonderful tag things for passing in such options, > they can be highly structured if necessary. > > 2. You don't or can't really understand and manage the failure, > want to wall off a whole subsystem, to contain an unknown failure > but otherwise, at best, just log it and try to reset/try again. > For this we have tasks and failure. Intentionally unrecoverable > until the task boundary, and intentionally not-very-typed. For category 2., as you mention, Rust has the mechanism of tasks and failures. The non-spawnability of closures has me a little worried, but I am sure that most/all useful cases can be encoded without this feature and since my current hands-on experience with Rust tasks and failures is essentially non-existing, I feel incompetent to discuss these in depth. However, this whole thread was about category 1 and, more precisely, about library-design of category 1, rather than language-design. For reporting exceptional behaviors, the "wonderful tag things" you mention are necessary, and a sufficient *language* mechanism, but stopping the *library* design at this point is inviting either the same mess as Haskell or OCaml or the same mess as mozilla-central. Both Haskell and OCaml have around 6 distinct – and largely type-incompatible – manners of reporting exceptions. This does not even take into account the fact that both OCaml and Haskell sum types are (or can be made) more flexible/powerful than Rust tags, something we probably do not want in Rust. On the other side, mozilla-central has only one mechanism, which has a fixed set of exceptions, and new exceptions can only be added by rebuilding the whole platform. In order to avoid both pitfalls, I advocate that we need to decide of a standard manner of reporting exceptions very early in the development of Rust – ideally before anybody starts writing or using any library that makes heavy use of exceptions, such as an IO library. The rest of the thread was about how to best offer standard library mechanisms for handling with exception reporting. I hope this clarified matters a little. Cheers, David
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
