Still, there are decent improvements we could make. Star, or better yet, comment on https://code.google.com/p/chromium/issues/detail?id=259443 with how you get caught out by weak error messages. We want the debugging cycle to be a lot more direct from error to fix.
SpiderMonkey has something that we call ExpressionDecompiler [1]. Basically it allows us to decompile some subset of the JS bytecode. Fun fact: At some point in time SpiderMonkey could actually decompile all bytecode and this is how we used to generate the result of Function#toString. [2]
It doesn't seem relevant to the bug you posted, but as long as you're here... I'm always annoyed by the vagueness of JSON.parse syntax errors. Instead of showing the source file and line number of the call to json.parse (or even better the location of the syntax error in the json string it failed to parse) I get "uncaught syntax error in index.html:1". I know now that that usually means i've forgotten to wrap a json.parse in a try..catch, but it's caught me out a few times.
Thank you. This will save so much development time globally.
Please also look into the "Script error" message. I know it is intentionally non-descript to prevent leaking information about cross domain requests but there has to be something that is safe to report that will help developers narrow down what is causing it.
Given developers can usually narrow it down after a bit of trial and error I see no reason to obfuscate this. By its nature all the source is available to anyone asking, so let's just stop making CORS debugging such a pain.
For those of you who argue that the US standard of living hasn't improved since the 70s: How do you defend your position in the face of this overwhelming counter-evidence?
This would help a lot in case where you have multiple calls chained together.
foo.bar().fiz().buz()
What's undefined, bar, fiz, or buz? Then you have to set a breakpoint to find out. Most people I know try to avoid writing code like this, but Knockout ViewModels are a common place where this bites me.
This is cool, although the title reminded me of one of my favorite parts of Elm[0]...I've effectively said goodbye to “undefined is not a function” because I've said goodbye to runtime exceptions in general.
More specifically, I have yet to write Elm code that compiles and throws a runtime exception. I sure don't miss seeing "undefined is not a function!"
How does Elm handle browser differences? For example, window.clipboardData.setData is only defined in IE, so what happens if I call it unconditionally from Elm, and am using Firefox?
After some research, it looks like my answer is that I can't call it unconditionally from Elm. Elm doesn't provide an easy way to access arbitrary JavaScript properties, and doesn't attempt to expose all of the functionality of the browser, but instead provides its own API.
This has been one of the biggest annoyances of debugging Javascript I can think of. Maybe it is rather small to many, but this is a big deal for me and I cannot wait for it to land in the stable version of Chrome (even though I am a Firefox user), I still test in Chrome.
This is one of my pet peeves with most languages' error messages - e.g in Ruby:
2.2.0 :001 > a = nil; b = " "; c = "a";
2.2.0 :002 > a + b + c
NoMethodError: undefined method `+' for nil:NilClass
from (irb):2
It would be trivial to tell me what the name of the nil variable was - in this case it's obvious, but it's often not.
Except in Ruby, that error is raised by `NilClass#method_missing`. `method_missing` gets to know the name of the method being called, and the arguments passed to it, but it deals with the value, not the variable. It wouldn't be "trivial" to report the name of the variable, it would probably involve intercepting all NoMethodErrors raised by NilClass and then dropping into the debugger to know where exactly execution stopped. I'm not sure this is even possible with the current architecture of the Ruby interpreter.
This is awesome! If there's one area that still needs a lot of work in the js world I think its exception messages. Its hard to believe its 2015 and its still so hard get clean stack traces for your minified js in production since you can't source map it there.
I wonder how large js apps handle production debugging and error reporting on all browsers? The last time I tried window.onerror it had decent support but not comprehensive support across browsers. Maybe its just me but this seems like a problem really needing to be solved, especially as js apps get bigger and bigger.
OP may be referring to jQuery's removal of the sourcemap comment last year, starting from 1.11/2.1 [0]. Basically, many sites deploy the minified library without the sourcemap, leading to tons of 404 errors which confuse users.
I saw the original link on my phone yesterday. The screenshots in the post were unreadable since pinch and zoom was disabled, so I didn't fully understand until pulling up HN on a larger screen today.
I have no idea how many other people might have read your submission on their phone and had the same issue though.
Can we get a properly working window.onerror? Currently we either get a very generic Script Error (0 information for debugging) or have to wrap every native method in one with a try/catch. This is more for error log collection and aggregation to understand what's breaking in production.
Someone should try it, but it seems unlikely if V8 is generating the error message. Dev Tools loads the source maps and as far as I know, V8 doesn't know about them.
Internet Explorer has stopped working
Windows is checking for a solution to the problem...
[||||||||||||||||||||||||||||||||||||||||||||||||||]
[ Cancel ]
Certainly a great improvement, but it's sad that the WebKit Dev Tools are well over a decade old, and this change is just coming now. It shows how much room there is for improvement in developer ergonomics.
This is awesome! "undefined is not a function" was one big problem for me when I started cleaning up code, and didn't know what caused the issue, I spend a lot of time debugging.
Still, there are decent improvements we could make. Star, or better yet, comment on https://code.google.com/p/chromium/issues/detail?id=259443 with how you get caught out by weak error messages. We want the debugging cycle to be a lot more direct from error to fix.