Filtering Errors

Stop recording errors you don't care about.

You can control which errors get posted to Errorception. Simply define a _errs.allow function that returns true or false. You could think of it as being similar to the native Array.filter method. Errors discarded because of this function are not posted to Errorception's servers, and hence do not count towards your daily rate limit.

_errs.allow = function(error) {
  `error` looks similar to the following:
    message: "Uncaught ReferenceError: p is not defined",
    line: 34,
    url: "",
    stack: "...stack trace..."

  return true;  // Allow all errors

If _errs.allow is undefined, all errors are posted to the server. The _errs.allow function receives an object representing the error as its first argument, which contains the error message, line number, the source script's URL, and the stack trace, when available.

As an example, if you don't care about errors from IE6, you could do the following:

_errs.allow = function() {
  return (navigator.userAgent.indexOf("MSIE 6") == -1);

Or, to allow all errors from and its subdomains:

_errs.allow = function() {
  return (location.hostname.indexOf("") != -1);

The data in the error object is the raw data Errorception captured from the browser. This data isn't fully sanitized yet. (Errorception does the bulk of the error processing on the server, so that your users don't face any performance lag.) As a result, you must not assume that any of the properties of the error object will be available. Ensure that you the property indeed exists before calling a method on it. Eg: error.stack && error.stack.indexOf("...").

Debugging note: Picture this: Let's say you have a bug in your _errs.allow function, that throws an error. The error thus raised would now go back through your _errs.allow function once again to determine if this new error should be posted, possibly raising another error. This could continue ad infinitum, causing the browser to hang! To prevent this infinite-loop-mess, if _errs.allow encounters an error, it isn't thrown as usual. Instead, Errorception swallows the error up. Meanwhile, since .allow broke, we couldn't determine if the original error should be posted to Errorception. So Errorception plays safe and chooses to record the original error regardless. In addition, Errorception posts the error that occurred when calling .allow to Errorception itself, causing the error in your .allow function to show up in your error logs as well.

Unfortunately, this does double the number of errors posted (the original error + the new error in .allow) when your intention might have been to reduce the number of errors in the first place. However, since this only happens in a corner case, and since you'd definitely notice such a problem, this behaviour has been left as is.