3 ms·

Solid approach if you really want to dig in problems occurring client-side in projects that are still in Beta. I'm not sure whether or not you would want this

Solid approach if you really want to dig in problems occurring client-side in projects that are still in Beta. I'm not sure whether or not you would want this in a production page.

philbarr 15y ago
Yes, this could generate an awful lot of network traffic in a production system. And since he's using ajax to log errors, and he's hooking into ajaxError, he might well have a serious problem on his hands if a problem occurs during the attempt to log errors. I agree with the sentiment though, even if it was a little preachy at the beginning.
- snprbob86 15y ago
  Yup. It's a pretty bad idea to log all errors from ajax calls, since some errors are expected. 403 and 404s, for example, should be handled relatively intelligently. Error-handling is a bitch, but you really need to do it thoughtfully for practically every remote call, similar to robust C code.
  - latch 15y ago
    You are right about the ajaxError..I'm not sure what I was thinking. I kept it in, but added a note that I was wrong.
snprbob86 15y ago
We do this on a product page, but with some modifications. As luck would have it, I recently made a Gist about this :-) https://gist.github.com/2210783 https://gist.github.com/2210783 Our approach integrates with a syslog-style logger. The logger preserves a ring buffer of messages, to help with debugging, since minified stack traces aren't super useful. To mitigate the risk of a run-away infinite loop alert monster, alerts are intelligently rate limited client side. We also do server side filtering, so that known/expected errors are ignored. For example, we don't really care about Chrome extension-related failures, although I guess we might at some threshold for popular extensions. It's relatively noisy, but so far it has been indispensable for debugging errors in production.
- dunham 15y ago
  We've been doing this for a few years in our GWT app. We also keep a ring buffer of log events. We don't have much noise, but we're using GWT's "unhandled exception" hook which I believe is driven by try/catch blocks on all entry points into the app. (i.e. event handlers - I think they just wrap callbacks before hooking them up.) So we only get exceptions that occur in our own code. For us, the stacktraces are actually very useful (on the few browsers that provide traces). We dump a translation table from GWT's minification process and use it on the server side to de-obfuscate the stack traces. It works on all of the function/method names, but not local variable names. The new javascript "source maps" technology should provide enough information to do this with any minifier or compiler. I'd expect your favorite javascript minifier to start outputting source maps in the next few months.
jrgnsd 15y ago
Would you care to elaborate?
- Kartificial 15y ago
  Various comments already pointed to problems that could come with a rough error-logging implementation. Because he used AJAX for every error, it creates a (unnecessary) strain on the network/server when in production. Besides this, the usefulness of the data logged may vary heavily. Therefore I suggest you do not log everything, like chrisacky points out. What exactly to log is an interesting resulting question. I do fancy the idea of logging problems client-side, because they result in users leaving your site but leaving you without a clue what happened.
  - latch 15y ago
    I think chrisacky has a good solution there as well. You just start to filter things you know you can't do anything about. The approach to rolling this out then might be to do it for only a small % of users at first so that it isn't overwhelming. You include more users as you notice that your manually created filters work.

Solid approach if you really want to dig in problems occurring client-side in projects that are still in Beta. I'm not sure whether or not you would want this in a production page.

philbarr 15y ago

Yes, this could generate an awful lot of network traffic in a production system. And since he's using ajax to log errors, and he's hooking into ajaxError, he might well have a serious problem on his hands if a problem occurs during the attempt to log errors. I agree with the sentiment though, even if it was a little preachy at the beginning.

snprbob86 15y ago
Yup. It's a pretty bad idea to log all errors from ajax calls, since some errors are expected. 403 and 404s, for example, should be handled relatively intelligently. Error-handling is a bitch, but you really need to do it thoughtfully for practically every remote call, similar to robust C code.
- latch 15y ago
  You are right about the ajaxError..I'm not sure what I was thinking. I kept it in, but added a note that I was wrong.

snprbob86 15y ago

We do this on a product page, but with some modifications. As luck would have it, I recently made a Gist about this :-) https://gist.github.com/2210783 https://gist.github.com/2210783 Our approach integrates with a syslog-style logger. The logger preserves a ring buffer of messages, to help with debugging, since minified stack traces aren't super useful. To mitigate the risk of a run-away infinite loop alert monster, alerts are intelligently rate limited client side. We also do server side filtering, so that known/expected errors are ignored. For example, we don't really care about Chrome extension-related failures, although I guess we might at some threshold for popular extensions. It's relatively noisy, but so far it has been indispensable for debugging errors in production.

dunham 15y ago
We've been doing this for a few years in our GWT app. We also keep a ring buffer of log events. We don't have much noise, but we're using GWT's "unhandled exception" hook which I believe is driven by try/catch blocks on all entry points into the app. (i.e. event handlers - I think they just wrap callbacks before hooking them up.) So we only get exceptions that occur in our own code. For us, the stacktraces are actually very useful (on the few browsers that provide traces). We dump a translation table from GWT's minification process and use it on the server side to de-obfuscate the stack traces. It works on all of the function/method names, but not local variable names. The new javascript "source maps" technology should provide enough information to do this with any minifier or compiler. I'd expect your favorite javascript minifier to start outputting source maps in the next few months.

jrgnsd 15y ago

Would you care to elaborate?

Kartificial 15y ago
Various comments already pointed to problems that could come with a rough error-logging implementation. Because he used AJAX for every error, it creates a (unnecessary) strain on the network/server when in production. Besides this, the usefulness of the data logged may vary heavily. Therefore I suggest you do not log everything, like chrisacky points out. What exactly to log is an interesting resulting question. I do fancy the idea of logging problems client-side, because they result in users leaving your site but leaving you without a clue what happened.
- latch 15y ago
  I think chrisacky has a good solution there as well. You just start to filter things you know you can't do anything about. The approach to rolling this out then might be to do it for only a small % of users at first so that it isn't overwhelming. You include more users as you notice that your manually created filters work.