Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Runtime errors should provide more context #234

Open
PK1A opened this issue Jul 8, 2014 · 5 comments
Open

Runtime errors should provide more context #234

PK1A opened this issue Jul 8, 2014 · 5 comments
Labels

Comments

@PK1A
Copy link
Contributor

PK1A commented Jul 8, 2014

As of today runtime errors don't provide enough context to pin-point the part of the code from which the error actually originates. For example, providing an invalid expression in the DOM event handler will result in the following error:

Uncaught ReferenceError: toggleSelectedRow is not defined

Ideally I would like to:

  • know what is a concerned template name
  • have a bogus expression visually standing out in the error message, for example by using quotes:

Uncaught ReferenceError: expression "toggleSelectedRow" was invoked from "/path/to.hsp" but is not defined

@dpreussner
Copy link

Also what about source maps? Would in not it also be possible if the hsp compiler produced source maps to also show the exact line in the template on which the error occurred?

@benouat
Copy link
Member

benouat commented Jul 8, 2014

This would be ideal !

@PK1A
Copy link
Contributor Author

PK1A commented Jul 8, 2014

Yes, it would ideal => an exception plus a line higlighted in the nu-processed file. But I think it will be challenging to do in practice as we are doing many transformations to a given hsp file (compilation, transpilation and potentially minification). I'm not sure how easy / hard would be to generate source maps that take several transformations into account....

@dpreussner
Copy link

@PK1A
I only had a quick glance at some source maps tutorials (e.g. http://blog.teamtreehouse.com/introduction-source-maps). But a least from my naive impression it seems doable as the main aspect is mapping the "new" function names to the "old" ones. My impression would be that the hashspace compiler might have this information already? But of course I only can guess if the mentioned transpile process interferes... So I still can not estimate how much effort it would be to generate source maps.But there seems to exist a reference implementation for generating source maps, which might be usable for this purpose: https://github.com/mozilla/source-map/

@PK1A
Copy link
Contributor Author

PK1A commented Sep 17, 2014

Runtime errors during expression evaluation now contain an expression in question which should aid in the debugging. Keeping this issue open if we want to add the file name in question this way or another. Not sure how to apply source maps to this problem but this is one idea of a solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants