Earlier quoted context omitted.
Stack traces for async code are always borderline useless in Javascript. Instead of telling me who called the offending code it just informs me that the code is executed by an scheduler in the event loop.
You create the error before doing the async operation, then throw/callback that error with additional info from the async error.
JavaScript debuggers are broken
21–30 of 124 posts
Re: JavaScript debuggers are broken
#22I remember IE5-6 ? Where it only told you there was an error, and you had to figure out where yourself via alert("this is line 500") Being used to that I think Chrome dev tools are amazing. I love that you get a call stack on every console.warn. All those console.log's can be removed in production via overloading or marking them as pure functions when minifying, as they will otherwise slow down the app. There's other…
Re: JavaScript debuggers are broken
#23Earlier quoted context omitted.
You create the error before doing the async operation, then throw/callback that error with additional info from the async error.
That sounds tedious in a web server where like half the functions are async. Also why is that my responsibility? A stack trace is supposed to show the call chain, not language implementation details. At a minimum `async x()` should just be equivalent to `try { async x() } catch(err) { throw new Error(err) }` (with the logger printing all nested exceptions)
Re: JavaScript debuggers are broken
#24Earlier quoted context omitted.
This is excessively common. Somehow modern debugging is essentially as nuanced as "shit broke". Debugging was far better 20+ years ago under C++ in win32 then it is today - there was working code navigation as well. I don't know how we have fallen so far back in the tooling.
PHP debugging is fine. Conditional breakpoints, walking up the stack trace, interactive and in-place code execution at run-time meaning I can run code or change variables and it applies to the current execution. It's great. Javascript is a nightmare to debug, but it's probably just as much to do with architecture than debugging tools. Of course it's hard to debug a dozen tiny libraries written in ES6, transpiled down…
Re: JavaScript debuggers are broken
#25Its interesting to see developers talking about and building debuggers whilst only apparently having experience of one. EDIT: apparently the following is no longer true From gdb, going to Chrome dev tools was super painful. I had been used to writing high quality watch statements. watch x, and break if it is is a very powerful debugging mechanism. Chrome has "pin this variable and tell me its value every time I pause…
if(x) throw x
You tend to operate on a data structure and know that at some point x becomes y. By placing a watch on x you find out where that point is.
Editing the code does not get you this (bar modern proxies in js).
Re: JavaScript debuggers are broken
#26I remember IE5-6 ? Where it only told you there was an error, and you had to figure out where yourself via alert("this is line 500") Being used to that I think Chrome dev tools are amazing. I love that you get a call stack on every console.warn. All those console.log's can be removed in production via overloading or marking them as pure functions when minifying, as they will otherwise slow down the app. There's other…
I wonder if this is the reason that js tends to fail silently or convert types whenever possible because debugging errors was just too hard.
Re: JavaScript debuggers are broken
#27Re: JavaScript debuggers are broken
#28Re: JavaScript debuggers are broken
#29Javascript is the only language I've worked with that doesn't offer a good debugger/breakpoint system, and I agree with the reasons/issues stated in this article. It makes working with JS (and Node) a real pain in the butt. IDEs such as VSCode offer integrated debuggers etc. and I wonder if anyone ever was able to use it for anything more than a few lines of vanilla JS. I can't seem to understand how those would work…