To clarify, the |aMessage| param is correct in this case, but the |ucMessage| member of the error report is null. Should I always be using |aMessage| whenever possible?
Created attachment 437939 [details] [diff] [review] Proposed fix IMO this is just a bug -- we should fill in report->ucmessage whenever we can (especially to avoid chopping wide characters passed to the Error constructor). I still think that the worker code should deal with not having a ucmessage, and fall back onto using |message| in that case.
Comment on attachment 437939 [details] [diff] [review] Proposed fix I'd really like to get this on 1.9.2. It fixes a hole in the error reporting mechanism that has been around for a while and breaks simple uses of 'throw new Error()' in script.
Comment on attachment 437939 [details] [diff] [review] Proposed fix a=beltzner for 220.127.116.11
Comment on attachment 437939 [details] [diff] [review] Proposed fix Do we want this on 1.9.1? Simple patch, no real risk, fixes the error report mechanism when doing a |throw new Error();| which is probably pretty common...
Comment on attachment 437939 [details] [diff] [review] Proposed fix a=beltzner for 18.104.22.168
Friendly notice: both the 22.214.171.124 and 126.96.36.199 code freezes are scheduled for *tomorrow*, Tuesday April 27th 2010 @ 11:59 pm PST.
Blake's patch doesn't apply cleanly to 1.9.1, he's going to take a peek and make sure it's a safe merge.
Ah, thanks Ben. Sorry for assigning this to you prematurely.