First, I'll confess I'm not a huge fan of MaybeLocal but, leaving that aside, even if I accept the utility of MaybeLocal I would expect it to be used for errors for which there's a reasonable hope of recovery and some way of actually testing the recovery code.
If Exception::Error returns an empty result, the world (or at least the Isolate) has turned to yogurt and I feel I can't rely on any API calls actually working so it seems like there's not much for me to do other than crashing and I would have preferred the crash closer to the point where the construction of Error actually failed (Factory::NewError). Beyond that, short of an extremely artificial test where I say hack the Error native constructors, I can't see how I could possibly test any error recovery code for an Exception::Error failure. To me this sort of error seems closer to out of storage errors than unusual results errors. All that said, I guess MaybeLocal<Object> Exception::Error is better than Local<Value> or MaybeLocal<Value> as it better documents what an embedder should expect though the former might be accompanied by a comment that the ToLocalChecked on the return value should only ever fail in the event of catastrophic errors so you might not want to expend much bandwidth on worrying about it. On Wednesday, February 10, 2016 at 7:55:01 AM UTC-8, Daniel Vogelheim wrote: > > Generally, the API tries hard to pass errors up. > > I wonder if we should return MaybeLocal<Object>, then. There's been a huge > APi refactoring in the past to deprecate returning empty Locals (or > Undefined, or so) as error markers, and instead signal all such failures by > returning an empty MaybeLocal. Not quite what Alex asks for, but IMHO more > consistent with the remainder of the API. > > > On Wed, Feb 10, 2016 at 4:26 PM, Alex Kodat <[email protected] > <javascript:>> wrote: > >> Thanks for that. I suspected as much. Is v8 really doing embedder's a >> favor by exposing such a catastrophe to them? Presumably, if >> Factory::NewError fails, we're out of storage (which v8 correctly doesn't >> do embedders the favor of exposing to them), there's some other >> catastrophic failure (like say the embedder's code has run amok clobbering >> the v8 heap), or the native Error constructors have a problem >> (inconceivable except maybe if a developer was fiddling with them). >> >> None of these seem like cases where it's useful to share the pain with >> the embedder code, especially as the situation is presumably that the >> embedder code wants to reflect an error to the JS but whoops, all it can >> get is an undefined from Exception::Error. Now what? >> >> Could I/should I open an issue for this? Sorry if this is a stupid >> question, I'm still not quite sure when it's appropriate to post to the >> list or open an issue. While I know you can code the change about as fast >> as I can hit the Post button, I'd be happy to make the change myself. FWIW, >> I'd do the type-checking and cast in Factory::NewError and have it (them) >> return a JSObject as it seems like it might be useful for other V8 code to >> be able to count on NewError giving it an object (like for example, the >> JSON parser?). Maybe this is too trivial to waste anyone's bandwidth on? >> >> On Wednesday, February 10, 2016 at 5:25:29 AM UTC-8, Yang Guo wrote: >>> >>> This probably never happens, but in case creating the error object >>> fails, undefined is returned. >>> >>> On Monday, February 8, 2016 at 9:03:42 PM UTC+1, Alex Kodat wrote: >>>> >>>> This must have been asked before but can't find an explanation so ... >>>> just curious why Exception::Error et al are declared to have a >>>> Local<Value> >>>> result instead of Local<Object>. A not uncommon pattern is to create a new >>>> Error object and then set some properties on it which requires a >>>> ->ToObject >>>> or Local<Object>::Cast on the Exception::Error result. Trivial, but it >>>> just >>>> seems odd that it's necessary. >>>> >>>> Thanks >>>> >>> -- >> -- >> v8-users mailing list >> [email protected] <javascript:> >> http://groups.google.com/group/v8-users >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
