Here's my take on this problem: http://codereview.chromium.org/3558004/show
There's a new FailureOr<T> template (http://codereview.chromium.org/3558004/diff/1/8) that is supposed to be used in allocation functions like this: FailureOr<JSObject> AllocateJSObject(Map* map); and in consumer functions like this: FailureOr<JSObject> object = AllocateJSObject(map); if (object.is_failure()) return object; // check and propagate. object->SetProperty(...); // operator-> requires a prior is_failure check in debug mode. FooBar(object.get()); // get() returns the object (also requires the check). // ~FailureOr<T> requires that the object was either checked or copied. In the patch linked above I only converted a few functions (it compiles and passes the tests). Until we have everything switched to FailureOr there are a few public helper methods adding unnecessary ugliness. I too agree that we should eventually get rid of automatic Failure to Object upcasting. These two types should only meet in really low-level places like the C++/JS boundary. What do you guys think? Thanks, Vitaly On Thu, Sep 30, 2010 at 3:00 PM, Kevin Millikin <[email protected]> wrote: > Just thinking out loud: instead of a base class that both Failure and Object > (couldn't it be HeapObject?) extend, you could use two separate channels. > Change all the allocation functions to take a HeapObject** and return a > error code. > Instead of: > MUST_USE_RESULT static Object* CreateJSValue(JSFunction* constructor, > Object* value) { > Object* result; > ALLOC_CHECK(result =, Heap::AllocateJSObject(constructor)); > JSValue::cast(result)->set_value(value); > return result; > } > You could have some variant of: > MUST_USE_RESULT static ErrorCode CreateJSValue(JSFunction* constructor, > Object* value, > HeapObject** result) { > ErrorCode code; > if (!(code = Heap::AllocateJSObject(constructor, result))) { > return code; > } > JSValue::cast(result)->set_value(value); > return ErrorCode::Success(); > } > It avoids the nasty macro that takes half an assignment expression as > argument. > On Thu, Sep 30, 2010 at 3:39 AM, Erik Corry <[email protected]> wrote: >> >> http://codereview.chromium.org/3522008 >> >> This is an experiment. The edits to objects.cc are done with an >> automated tool and are intended as an illustration. They probably >> don't compile. Would this be a win and can anyone think of a neater >> way to do it? >> >> -- >> Erik Corry, Software Engineer >> Google Denmark ApS - Frederiksborggade 20B, 1 sal, >> 1360 København K - Denmark - CVR nr. 28 86 69 84 >> >> -- >> v8-dev mailing list >> [email protected] >> http://groups.google.com/group/v8-dev > > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
