4 ms·
The fact that tools like this are needed should be understood to mean that JavaScript error handling is fundamentally broken. In a reasonable language, you do
by kerkeslager 9y ago
The fact that tools like this are needed should be understood to mean that JavaScript error handling is fundamentally broken.
In a reasonable language, you do something obviously wrong, and it throws an exception immediately, which gives you a stack trace that gives reasonable context for understanding what went wrong.
In JavaScript, the failure often happens silently: "foo" + 1 returns "foo1", {}.foo returns undefined, and program execution continues until it absolutely can't, finally failing far away from where the problem occurred. And when it does fail, it often fails in a callback deep within framework code with no clear, traceable execution path that leads back to the point where the error occurred. The errors have all the mysteriousness of C errors, without even the traceability.
The JavaScript community doesn't seem to be aware that there are better solutions, and seem happy with the way things are, even going so far as to use JavaScript on servers where far better tools exist. It seems that the only salvation that will come will be when mature tools exist on top of WebAssembly so that those of us who care about error reporting can use better toolchains.
- brlewis 9y agoYou need a tool like this to monitor run-time browser errors. When browsers support a language that catches 100% of errors at compile time then you won't need tools like this. But I see what you're saying. Except for the declarative style popularized by React and also implemented in Mithril, Preact and Inferno, and except for the rise in popularity of TypeScript, and except for a lot of attention paid lately to immutable data structures, and except for jslint being created in 2002 and lots of similar tools since then, and except for the wide variety of JavaScript-based unit test frameworks, it really seems like the JavaScript community has no clue that there are ways to prevent the errors you describe and no inclination to prevent them.
- kerkeslager 9y ago> You need a tool like this to monitor run-time browser errors. When browsers support a language that catches 100% of errors at compile time then you won't need tools like this. Eh, I don't think that logging runtime-in-the browser is the value added here. I can wrap my codebase in a try-catch that catches exceptions and calls home with the stack trace in < 100 lines of code. Avoiding that < 100 lines of code isn't the value added.
- mankz 9y agoYou could, but the point is that the stacktrace is useless in most apps (unless you have stateless minimalist website). As soon as you make a web app and you have state - stacktrace doesn't help reproduce the bug.
- kerkeslager 9y ago> As soon as you make a web app and you have state - stacktrace doesn't help reproduce the bug. It does in a reasonable language. That's my point.
- brlewis 9y agoWhat's an example of a reasonable language that has state? I figured you had to be thinking of a pure functional language.
- kerkeslager 9y agoPython, Ruby... the concern isn't so much state as that it throws the exception where the mistake actually happens instead of failing silently.
- kerkeslager 9y agoDo people care to explain their downvotes, or is it just people getting offended because I criticized their language?
- ggregoire 9y agoI didn't downvoted you but your comment is off topic and kinda wrong. Off topic because this service is a logging service to log JS errors in production. It's not related at all with how JavaScript handles errors. Kinda wrong because even in "a reasonable language", you still need to log errors, warnings and other stuffs. It's absolutely not specific to JavaScript. Actually, JavaScript didn't have any serious logging solutions like Sentry, Loggly or RootCause until really recently. It's great to see all these new tools.
- kerkeslager 9y ago> Off topic because this service is a logging service to log JS errors in production. It's not related at all with how JavaScript handles errors. Logging errors can be done in <100 lines of JavaScript, so if that were the value added of this service, they would be in trouble. The value of this service lies more in the ability to replay state so you can debug JavaScript, which is absolutely related to how JavaScript handles errors. If JavaScript handled errors better, this wouldn't be necessary.
- ggregoire 9y ago> Logging errors can be done in <100 lines of JavaScript, so if that were the value added of this service, they would be in trouble. No it cannot. You need a backend to send and store the logs, a dashboard with some grouping/filtering features to analyze anything, an alerting system to send you daily/weekly emails, user/group/permission management if you don't work alone, and so on. Don't act like this guy who said Dropbox has no value because it's trivial to make a FTP account online and sync it with your machine.
- kerkeslager 9y ago
- Can_Not 9y ago> In a reasonable language, you do something obviously wrong, and it throws an exception immediately, which gives you a stack trace that gives reasonable context for understanding what went wrong. So how is it even possible that this tool works if JavaScript doesn't do this? I don't know why you're just making things up.
- kerkeslager 9y agoThe tool allows replays of state, which allows you to reverse execution back to the point where the error occurred. If you think JavaScript throws errors immediately when you do something obviously wrong, try evaluating the following expressions in your console: {}.foo "foo" + 1 undefined + 1 None of these return any sort of error until much later when you get an exception like "Undefined has no properties", or worse, no exception at all just "foo1" or "NaN" printing in a place you expected an actual number. Good luck trying to debug any of these situations if the result gets passed to a callback and the actual exception finally occurs inside a promise inside a callback.
- deleted 9y ago[deleted]