I like the idea of pulling in some Rusty concepts, but I'm concerned about adding yet another early return macro -- absolutely no arguments on the new type, just the |MOZ_TRY| macro. In practice these have lead to security issues (UAF, etc) and memory leaks in the C++ world (I'm looking at you NS_ENSURE). These aren't hypothetical issues, I've run into them both working on memshrink and sec issues in Firefox.
A reasonable defense is that we should RAII-all-the-things, and believe me I get it, but we're working on a 20 year old C++ codebase at this point and we have to deal with what we have. If we really want the benefits of Rust we should be writing components in Rust, not trying to make C++ look like Rust, but you know, without the memory safety guarantees. -e On Wed, Dec 21, 2016 at 9:53 AM, Ted Mielczarek <t...@mielczarek.org> wrote: > On Wed, Dec 21, 2016, at 12:30 PM, Jason Orendorff wrote: > > The implicit conversion solves a real problem. Imagine these two > > operations > > have two different error types: > > > > MOZ_TRY(JS_DoFirstThing()); // JS::Error& > > MOZ_TRY(mozilla::pkix::DoSecondThing()); // pkix::Error > > > > We don't want our error-handling scheme getting in the way of using them > > together. So we need a way of unifying the two error types: a shared base > > class, perhaps, or a variant. > > > > Experience with Rust says that MOZ_TRY definitely needs to address this > > problem somehow. C++ implicit conversion is just one way to go; we can > > discuss alternatives in the bug. > > The `try` macro in Rust will auto-convert error types that implement > `Into<E>`, AIUI, but that's not automatic for all error types. I haven't > tried it, but I have seen multiple recommendations for the `error_chain` > crate to make this smoother: > https://docs.rs/error-chain/0.7.1/error_chain/ > > It's basically just boilerplate to implement conversions from other > error types. I wouldn't be surprised if something like that percolates > into the Rust standard library at some point. > > -Ted > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
