From:  "Fitzgerald, Nick" <nfitzgerald@mozilla.com>
Date:  21 May 2013 06:57:14 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.js-sourcemap
Subject:  

Re: What should happen to errors in translation

NNTP-Posting-Host:  63.245.216.66

Hi Peter,

On 5/20/13 1:03 PM, Peter van der Zee wrote:
> This may not be the right place, but what should browsers do when an error
> is raised in an area of the translated code? As a dev I would not like to
> be sent to a wild goose chase, only to find out later that the error wasn't
> due to my code but due to the way it was translated.
>
> Should the browser make note of this (can it even know?)? Should it just
> let the user figure this out?

I'm not 100% sure what kind of errors you mean, can you give an example?

Firefox's debugger's "pause on exceptions" feature should work perfectly 
well with source maps, and if you can find a case where it doesn't then 
please file a bug ;)

If the compiler creating the source map has done a poor job, there isn't 
much we can do, and that is really the compiler's responsibility.

If there is an error at a null mapping, it is generally either an error 
in the prologue generated by the compiler, or a bad source map. Once 
again, not really the browser's responsibility, but it would be nice if 
the user had some indication of what is going on.

At Mozilla, we made the architectural decision not to source map stack 
frames in the JavaScript engine (such as those attached to Error() 
objects) due to potential security issues. On top of that, we don't have 
to block js execution until we have a source map whenever we get errors 
and are creating Error() objects. Furthermore, it avoids having whether 
or not you can fetch a source map from changing the path of running code 
if it is trying to reflect on the stack frames. If this is the scenario 
you are talking about, I'd suggest porting the source-map-support npm 
module[0] to the web.

Hope this helps,

Nick

[0] https://github.com/evanw/node-source-map-support